------- Comment #6 from marc dot glisse at normalesup dot org 2006-04-28 21:57
-------
(In reply to comment #4)
> Should all those private classes and functions be declared in some
> specific namespace std::glibcxx_private to have a single point of failure?
Oups, I just noticed that was one of the roles of __gnu_cxx (although I don't
understand why this namespace is not a subnamespace of std:: as tr1 (or at
least contains a using namespace std;), which would at the same time fix things
like getenv not being prefixed by std:: in ext/mt_allocator.h). So in this case
it would seem reasonable to move the classes to that namespace.
(In reply to comment #5)
> Again, I
> encourage you to post on the libstdc++ list a careful analysis of the issue,
> complete of mini-patch (fixing only one header, for example). At this point
> what you mean by "playing around" is not at all clear.
I had posted this bug report because I found it quite independant from the
rest. It is easy to see on solaris that __cplusplus>=199711L declares a
function __cos in namespace std, and I think I read somewhere that changing tha
value of __cplusplus was being considered.
I will eventually post something on the libstdc++ mailing list, but I am slowed
down by several things:
- I have only limited access to solaris 8 and 9, and several things would
require solaris 10 to work properly (at least it would be less work)
- the _GLIBCPP_USE_NAMESPACES in glibc has dozens of bugs (besides design
issues), to the point that doing: namespace std { #include <foo.h> } actually
works better than defining the macro right now...
- tracking why and where all the macros like __USE_GNU are defined is a
nightmare
- it may not be possible to work on each header independantly, because headers
include other headers
But I haven't quite given up hope yet. Depends how much time I will get to work
on this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
