Re: namespace pollution

[Benjamin Kosnik <bkoz at redhat dot com>]

> Generally, as a compiler/library user, I've always operated under the
> assumption that if I dont directly #include anything other than the standard
> headers, I shouldnt have to worry about name clashes with any name not reserved
> by the standard.  

this seems perfectly reasonable.

> #include <locale>
> 
> struct iconv
> {
>    iconv (char const *) throw ();
>    ~iconv ();
> };
> 
> int
> main ()
> {
>    iconv *i = new iconv ("?");
> }
> 
> This wont compile with the current library because one of the headers
> indirectly #included from locale is iconv.h which defines a function iconv. 
> This is not, to the best of my knowledge, a reserved symbol.  That the
> compilers error message, "`i' undeclared (first use this function)", doesnt
> actually tell me whats really wrong doesnt help either.

It's not a reserved symbol, being part of the standard unix
specification.

> My thought is that any non-standard symbols used by the library be placed in an
> implementation reserved namespace and if they are imported into namespace std,
> be given an implementation reserved name.  ie for bits/codecvt.h (the header
> that #includes iconv.h) we might have something like

Yep. I'll check in a patch to codecvt.h that does this. The other area
that is also effected is the use of nl_langinfo.h and nl_langinfo. I'll
patch this stuff up at the same time. Thanks for bringing it to my
attention.

-benjamin