Anonymous Namespaces

[Gabriel Dos Reis]

espie@quatramaran.ens.fr (Marc Espie) writes:

| >If you're having trouble with unit-at-a-time not recognizing functions
| >in unnamed namespacen, then the right course of action to do is to teach
| >that programmed inliner to recognize those functions.  Asking for
| >deviating from standard semantics is wrong.
| >
| 
| I'm surprised by this fact.
| I had been told anonymous namespaces were equivalent to static, but
| better. 

The "equivalent to static" is not right -- as you can determine by its
interaction with name lookup results.  I won't comment on "better".

| Now, if anonymous namespaces don't allow us the same potential
| optimization that static used to, what I've been told is completely
| wrong.

I think there is two separate issues here.

  (1) What static means in the language (e.g. interaction with things
      like name lookup)

  (2) what optimizations that can be applied to things that can be used
      only once, and in in a given translation unit.

In certain circumstances certain optimizations (like the one proposed)
can be applied based on "static".  However, such optimizations do
not require "static", they only require an assumption that happens to be
met by "static" in some cases.  The real assumption is that of a
thingy that can  be used only once in a program and in a given
translation unit.  What is happening in GCC is that we fail to spot
non-static cases.  And some  are suggesting to make them just "static". 

Indeed, what you have been told is wrong.  There is only a partial
truth in it.  

| Is this a foresight from the standard, a weird implementation choice
| of gcc, a misconception on my part or what ?

The interaction with name lookup is  was not a foresight.  What
however is a thinko is the "deprecation of static for function
declaration" (and if you look it does not deprecated the use of
"static" in general.  In fact static cannot go away, because it has a
different meaning than what unnamed namespace do).

-- Gaby