"Bronek Kozicki" <brok@rubikon.pl> wrote in message
news:dioua4$pn0$1@inews.gazeta.pl...

> Bronek Kozicki wrote:
>> actually, during Boost regression testing we found some problems with its
>> variadic macros (these appeared to be no macros at all). But it
>
> . just minor correction. The problem is not with macros, but va_list type
> which seems to be defined in the wrong namespace.

If you're expecting that including <stdarg.h> will define va_list
in namespace std, you're out of luck -- and not just with our
library. We *can* do that, if you use our C library too; with a
"native" C library we don't have much of a chance (Nor does
anybody else.). But most of the time we don't bother even with
our own C library, for reasons that have often been discussed
in this newsgroup.

There's widespread support for changing the next version of the
C++ Standard to (finally) accept today's reality about the use
of namespaces in Standard C headers.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Bronek Kozicki" <brok@rubikon.pl> wrote in message
news:dirrqu$m98$1@inews.gazeta.pl...

> P.J. Plauger wrote:
>>>. just minor correction. The problem is not with macros, but va_list type
>>>which seems to be defined in the wrong namespace.
>>
>> If you're expecting that including <stdarg.h> will define va_list
>> in namespace std, you're out of luck
>
> well, obviously I do not.

Sorry, but that *wasn't* obvious, given the endemic confusion about C header
namespaces caused by the C++ Standard.

>                                         And the problem I mentioned  does
> not apply to Dinkumware library, but compiler itself (surprise). Soon it
> will be gone anyway, as new version of the compiler is on its way.

Yes, privately you told me enough that I could figure out the problem.
It seems that the EDG front end, in its zeal to work with as many
libraries as possible, does its level best not to peer inside the
header <stdarg.h>, and more recently <cstdarg>. This causes trouble
for those of us who provide replacements that do nontrivial things.
You can outsmart the front end, but it takes a bit of work that Comeau
is only recently getting done.

This whole discussion began after I asserted that the combination
of EDG front end and Dinkumware libraries was a completely
conforming implementation. The counter assertion was that it
failed at least one conformance test used by Boost. It is
important to realize that any practical compiler component has
a gazillion options for interfacing to existing compilers and
libraries. Not all of those options produce completely conforming
behavior, for good and proper reasons. But there's a world of
difference between a product that *can* be used in a
nonconforming way and one that *can't possibly* be used
in a completely conforming way. A front end that lacks support
for export templates is in the latter category, as is a library that
lacks all the C95 and C++98 additions in its C library
component. Pointing out issues like EDG's optional treatment
of <stdarg.h> merely muddies the water.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Note that the recent type_traits addition does assume some compiler
capabilities that AFAIK are still unspecified. i.e. things like is_pod,
is_union, etc. Does anyone know of proposals to add these capabilities?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

When the C++ standard committee considers adding a new class to the
standard, how important is it for the class to be able to compile to
non-compliant (pre-standard) compilers like VC++ 6.0?

In other words, if there's a class that is fully compliant with the
C98 C++ standard, but does not compile on VC++ 6.0, would that pretty
much kill or greatly reduce the chances of the class being added to the
standard?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Axter" <google@axter.com> writes:

> When the C++ standard committee considers adding a new class to the
> standard, how important is it for the class to be able to compile to
> non-compliant (pre-standard) compilers like VC++ 6.0?
>
> In other words, if there's a class that is fully compliant with the
> C98 C++ standard, but does not compile on VC++ 6.0, would that pretty
> much kill or greatly reduce the chances of the class being added to the
> standard?

No, we don't make allowances for non-compliant compilers.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Axter <google@axter.com> wrote:
> In other words, if there's a class that is fully compliant with the
> C98 C++ standard, but does not compile on VC++ 6.0, would that pretty
> much kill or greatly reduce the chances of the class being added to
> the standard?

I doubt so. However, as currently there is no 100% compliant compiler,
if there is no way to implement said class depending on some obscure
(and often not implemented) feature of the language, IMHO its chances to
be accepted would be pretty small.


B.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Bronek Kozicki"" <brok@rubikon.pl> wrote in message
news:26fe1$434cca87$53f487c2$1293@nfa1.news-service.com...

> Axter <google@axter.com> wrote:
>> In other words, if there's a class that is fully compliant with the
>> C98 C++ standard, but does not compile on VC++ 6.0, would that pretty
>> much kill or greatly reduce the chances of the class being added to
>> the standard?
>
> I doubt so. However, as currently there is no 100% compliant compiler,

Uh, I believe that EDG's front end has been about 100% as you can
get for a couple of years now, as are Dinkumware's C and C++ libraries.
Aside from the numerous OEMs who license both our components, you can
assemble your own compliant compiler from Comeau's inexpensive
compiler package and a package from our web site.

> if there is no way to implement said class depending on some obscure (and
> often not implemented) feature of the language, IMHO its chances to be
> accepted would be pretty small.

Unless it was called auto_ptr. (Supply your own emoticon here.)

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]