Re: namespace pollution

[Phil Edwards <pedwards at disaster dot jaj dot com>]

On Fri, Sep 22, 2000 at 11:00:24AM -0700, Steven King wrote:
> 
> 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.

It's not mentioned in the C++ standard, but I don't know which standard
defines it.  (C, POSIX, etc)  I don't think it's C.  I'm fairly certain it's
"standard" but don't know whose.


> That the
> compilers error message, "`i' undeclared (first use this function)", doesnt
> actually tell me whats really wrong doesnt help either.

That is somewhat funky.  What happens if you change the declaration to

  struct iconv *i = new struct iconv ("?");

I don't have a compiler to test with.


> 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
[...example...]
> The reason I'm bring this up, is at the very least it impacts the shadow header
> layout.
> 
> Any thoughts?  Objections?  Alternatives?

We should first find out whether iconv should be treated as reserved.
If it isn't, then your suggestion sounds good.

Ironic that it would be in _C_legacy:  iconv is for character conversion
between things like old 7-bit ASCII and new-fangled schemes like Unicode,
after all, and "legacy" code is more likely to *not* be using iconv.  :-)


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.