This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: gcc 3.0 cannot compile pooma


> From: Zack Weinberg
> ...
> It seems to me that something like this should do just as well and be
> less fragile.
>
> <example excised> 
> 
> The separate internal namespaces for each C header are because you
> don't want to drag in everything from _every_ C header just because
> the user asked for everything from _one_ C header.

Headers are allowed to include other headers.  Putting the contents
of each forwarded header (and its subincludes) into a separate
namespace would have profound and unforseen consequences.  Not unlike
those we're getting now with the string.h header.

The problem arises because of the header guards.  The only way you can
maintain idempotence is by putting the contents of all the libC headers
into the same namespace.

> Note that if this works, then I don't think it's necessary to provide
> shadows for C headers not specified by C++98, which makes life
> considerably simpler.

It's required to provide shadows for the transitive closure of all
headers included or subincluded because if one was included
directly or indirectly by a <c...> header, it would have all its
names in the wrong namespace the next time they were needed.

Of course, trial and error has proved to me "all" doesn't really
mean all.  It turns out there are some headers that explicitly
shouldn't be shadowed (I forget why, it was late at night when I
hit that particular wall).  I believe some of those headers are
target specific.

Really, though, wrapping all the headers isn't the hard part.

> Note2, that in this scheme, nonstandard typedefs in a C header will
> only be aliased into the global namespace by the shadow header.  I
> don't see any way around that and I think Nathan's scheme has the same
> problem.

There is no way around that as long as the C++ heades are imlemented
on top of the C headers.  The problem does not occur if both headers
are built on the same foundation (ie, the "Solaris 8" style headers)
which is beyond the scope of gcc, or if the C++ headers are completely
independant of the C headers (excepting the Appendix D headers), which has
its own problems with supporting nonstandard names and stuff.

_______
Stephen M. Webb 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]