[Bug c++/28514] [4.2 Regression] libstdc++ vs. anonymous namespaces

[bkoz at gcc dot gnu dot org]

--- Comment #11 from bkoz at gcc dot gnu dot org  2006-10-17 11:48 ---

OK. I've reverted these anonymous namespace conversions.

Namespace that are just trying to squester name lookup should be spelled as
nested "detail" namespaces. Namespaces that are trying to prohibit exports via
internal linkage should be anonymous namespaces. 

I believe this usage is now uniform.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514

[Bug c++/28514] [4.2 Regression] libstdc++ vs. anonymous namespaces

[jason at redhat dot com]

--- Comment #10 from jason at redhat dot com  2006-09-07 00:14 ---
Subject: Re:  [4.2 Regression] libstdc++ vs. anonymous namespaces

bkoz at gcc dot gnu dot org wrote:
> This is precisely one reason why anonymous namespaces are useful. It provides 
> a
> very viceral way to sanity check an API. Make sure that the private parts
> really are private, say.

Yes, but there's a difference between private and internal.  This is 
especially problematic for templates; if you give template 
instantiations internal linkage, we can't share them between translation 
units anymore and you get code bloat.  Do you really want a copy of the 
list of primes from the hashtable policy code in each translation unit 
that uses it?

It seems to me that Rope_constants, _Private in  and the 
hashtable policy stuff were in special namespaces just to avoid name 
lookup pollution.  If you really want them also to be unique to each 
translation unit you could insert an anonymous namespace inside the 
preexisting namespace and not have to mess with name lookup at all.

I thought after my earlier comments you would put Rope_constants back, 
but now that I actually look at what you checked in I see that you just 
added explicit global scope to the uses.  That kind of cluttering up of 
the global namespace seems like a mistake to me; _Tag isn't a very 
unique name.  Changing _Private to an anonymous namespace has the same 
problem, except it's only cluttering up tr1 instead of the global 
namespace.  In both cases inserting an anonymous namespace inside the 
named namespace seems both better and less work.

> Please, let's leave  out of it.

You reported a problem compiling , it's hard to respond without 
talking about .

> I think that there are good reasons to use anonymous namespaces in headers,
> even if you disagree with these designs personally.

Please elaborate.  Why do you want _Tag, _Select, X::primes, etc. to be 
unique to each translation unit?

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514

[Bug c++/28514] [4.2 Regression] libstdc++ vs. anonymous namespaces

[bkoz at gcc dot gnu dot org]

--- Comment #9 from bkoz at gcc dot gnu dot org  2006-09-04 15:22 ---

> Furthermore, defining _Tag in an anonymous namespace will cause the compiler 
> to
> give all functions with _Tag in their signature internal linkage.  I don't
> understand why you would want this.

This is precisely one reason why anonymous namespaces are useful. It provides a
very viceral way to sanity check an API. Make sure that the private parts
really are private, say.

Please, let's leave  out of it.

I think that there are good reasons to use anonymous namespaces in headers,
even if you disagree with these designs personally.


-benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514

[Bug c++/28514] [4.2 Regression] libstdc++ vs. anonymous namespaces

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2006-07-31 08:20 ---
In general, I think using the anonymous namespace in headers is not what you
want.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514

[Bug c++/28514] [4.2 Regression] libstdc++ vs. anonymous namespaces

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2006-07-31 08:16 ---
The testcase gives the same errors for me when compiled as normal C++ as in PCH
mode.

The problem seems to be that you're removing the Rope_constants namespace name
and creating a name lookup collision between the _S_concat enumerator and the
_S_concat function in rope.

Why would you want to mess with Rope_constants, anyway?  It doesn't have any
symbols in it, it just controls name lookup.  When you take it away, name
lookup changes, and things blow up.  Moving them to the anonymous namespace has
the same effect for name lookup as declaring them directly in __gnu_cxx.

Furthermore, defining _Tag in an anonymous namespace will cause the compiler to
give all functions with _Tag in their signature internal linkage.  I don't
understand why you would want this.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514

[Bug c++/28514] [4.2 Regression] libstdc++ vs. anonymous namespaces

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2006-07-29 05:25 ---
I think this is 4.2 regression now but I need to reduce it.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|libstdc++ vs. anonymous |[4.2 Regression] libstdc++
   |namespaces  |vs. anonymous namespaces
   Target Milestone|--- |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514