Allow __cplusplus=199711L to work with Solaris 2 headers
Marc Glisse
marc.glisse@inria.fr
Mon Mar 14 21:39:00 GMT 2011
On Mon, 14 Mar 2011, Jonathan Wakely wrote:
> The Solaris headers think that when included by a C++ compiler they
> should define those overloads. The libstdc++ headers think that the C
> library won't provide them, so it provides them. Neither is "wrong"
> it's just a mistaken assumption.
>
> IMHO the right fix would be for libstdc++ to be aware that it's got a
> cooperative C library that want to help and provide some of those
> overloads. I believe the original libstdc++ design was that one of
> the libstdc++-v3/include/c_* directories would contain headers
> designed to work with a cooperative C library, but I don't know what
> the status of those directories is.
It is hard to decide exactly how cooperative the libc is. Especially with
C++0x where solaris will become half-cooperative, with possible variants
depending on the exact version. The technique started with cstring and
others using macros like __CORRECT_ISO_CPP_STRING_H_PROTO doesn't look too
hard to generalize, and might even provide a reason to improve glibc.
Note also the slightly confusing situation where after including math.h
cos(2) will fail to compile whereas it will work after including cmath.
(one of the c_* directories lets libstdc++ ship a math.h header that
includes what it needs (cmath) with #include_next for the real math.h)
If there's going to be a directory specific to solaris, note that it could
also do the proper C++03 thing and have cstdlib include iso/stdlib_iso.h
and not stdlib.h and thus have the clean global namespace that is not
required anymore by C++0x.
An alternative to the whole thing is to cheat in one of many ways to
act as if __cplusplus__ was still 1 in those headers.
--
Marc Glisse
More information about the Libstdc++
mailing list