namespace issues with old C headers

[David Schultz]

On Sat, Apr 12, 2003, Gabriel Dos Reis wrote:
> David Schultz <das@freebsd.org> writes:
> 
> | On Sat, Apr 12, 2003, Gabriel Dos Reis wrote:
> | > David Schultz <das@FreeBSD.ORG> writes:
> | > | sure why it is problematic.  In C, it is actually required that
> | > | standard headers not pollute the namespace with symbols from other
> | > | headers, lest standard C programs fail to compile.  Perhaps C++
> | > | differs in this regard, but that doesn't explain why this idea is
> | > | ``unrealistic.''
> | > 
> | > C++ definitely has a different requirement:  It allows a standard
> | > header (not a C-iniherited one) to include another standard header.
> | > And in effect, if a standard function implementation needs to use
> | > (reasonably) another stanadrd function, I don't see why it should not
> | > be permitted to include the appropriate header. 
> | 
> | Avoiding namespace pollution is somewhat helpful for application
> 
> #includeing standard headers does not pollute library and application
>  programmers' namespace -- since the only namespace that gets "affected"
> is ::std -- so I can't see what you're driving at.

The explanation was the part you cut when you quoted me.  :-P
I'm not talking about namespace pollution.  Promiscuous includes
mean that I can't count on the compiler to catch me when I
accidentally leave out a #include.  My code might compile on GNU's
C++ library version foo, but not version bar, and certainly not in
someone else's libstdc++ implementation.  This is a minor point,
but I think it shows that getting rid of promiscuous includes is
a moderately good thing, assuming you are willing to cope with
the added complexity.  Perhaps you are not, and as I have already
mentioned, I am not prepared to argue this point.

> | > The intent wasn't to shut down all of your proposed solutions.
> | > I'm more interested in a "real" solution and none of what you proposed
> | > seems to address the real problem.  I see Loren is working a
> | > patch that might give real solution.
> | 
> | I agree that none of my proposals were perfect;
> 
> I'm making a distinction between "perfect" and "real solutions".
> As I said, none of what you proposed really solved the problem.
> I'm not speaking of "perfection", it is something on cares about when one
> has a choice.

Aah, okay.  Could you perhaps explain how the Loren's patch you
mentioned solves the problem, since I'm still not sure where
you're going with this?

I admittedly do not have a deep interest in libstdc++.  You
probably gathered that much from the fact that I am not familiar
with the standard or any changes in the language in the last few
years.  I am, like yourself, opposed to kludgy solutions, which is
why I posted to this list instead of trying to work around the
problem.  But I also get the distinct impression that there isn't
presently a solution that is both good and portable.  In that
case, getting rid of promiscuous includes sounded like a 99% fix
for the problem, _and_something_that_ought_to_be_done_anyway_.
It's fine with me if you reject the idea, but I would like it to
be because you have a *better* one that doesn't involve waiting
for Bjarne to publish a new edition of his book.  ;-)