------- 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 <tr1/random> 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 <rope> out of it. You reported a problem compiling <rope>, it's hard to respond without talking about <rope>. > 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
