This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: namespace issues with old C headers
On Sat, Apr 12, 2003, Gabriel Dos Reis wrote:
> David Schultz <das at FreeBSD dot 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
writers because they don't need to worry about leaving out an
include such that their program still compiles with one C++
library but not another. But if the standard is silent on the
issue and you would like to avoid the added complexity, I can't
really argue.
> | In any case, you have shot down all of my proposed solutions,
>
> 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; that is why I
posted three of them. Is Loren working on a patch other than the
one he mentioned in this thread? That patch will, as I
understand, solve a more general but orthogonal problem. For
instance, even if libstdc++ knows when to include or omit 'long
long' support, it will not be able to tell if someone #includes
both <math.h> and <cmath> and expects the symbols to appear in two
namespaces. Is there something I missed? In short, it would be
great if a perfect solution existed, but the closest I've heard so
far is the (presently unsupported) #scope/#endscope proposal.