KDE FAQ states using static functions is better than putting themin an anonyous namespace

[Asfand Yar Qazi]

For years, I've been putting everything that won't be needed outside a
compilation unit in anonymous namespaces, even editing my old files that did
things the 'old' way (using static linkage). Then suddenly I find this in the
KDE developer faq:

Q: 2.24. I put some functions in anonymous namespace and someone reverted it
and made those functions static, why?
Symbols defined in a C++ anonymous namespace do NOT have internal linkage.
Anonymous namespaces only give an unique name for that translation unit and
that is it; they don't change the linkage of the symbol at all. Linkage isn't
changed on those because the second phase of two-phase name lookup ignores
functions with internal linkages. Also, entities with internal linkage cannot
be used as template arguments

Is that true? What are the implications of this? Should I now go around all
my source files and make functions/global variables declared in them static?

 

[Ivan Vecerina]

: For years, I've been putting everything that won't be needed outside a
: compilation unit in anonymous namespaces, even editing my old files that
did
: things the 'old' way (using static linkage). Then suddenly I find this
in the
: KDE developer faq:
:
: Q: 2.24. I put some functions in anonymous namespace and someone
reverted it
: and made those functions static, why?
: Symbols defined in a C++ anonymous namespace do NOT have internal
linkage.
: Anonymous namespaces only give an unique name for that translation unit
and
: that is it; they don't change the linkage of the symbol at all. Linkage
isn't
: changed on those because the second phase of two-phase name lookup
ignores
: functions with internal linkages. Also, entities with internal linkage
cannot
: be used as template arguments
:
: Is that true? What are the implications of this? Should I now go
around all
: my source files and make functions/global variables declared in them
static?

From the language's point of view, anonymous namespaces are a cleaner,
more general solution. As pointed out, external linkage is required
for some C++ features to be used (such as the mentioned template
instantiation). Also, 'static' linkage cannot apply to type definitions
such as struct-s or classes, and this keyword is already heavily
overloaded.
So anonymous namespaces offer a cleaner and more general mechanism,
and 'static' globals were deemed as 'deprecated'.

In practice, however, some prefer to use static, because anonymous
namespaces present some overhead (mainly in terms of long identifier
names stored in object files and in shared libraries).
In a way, they 'leak downstream' (i.e. to the linker etc) information
that the developer knows is not needed at all.


In practice, if both options are equivalent, I do not bother
converting any code. Use anonymous namespaces if they
are needed ( type definition, template... ).
In all other cases, it is a matter of choice. I will use
static if all I need is a local utility function or two.


I hope this helps,
Ivan

 

[Pete C]

For years, I've been putting everything that won't be needed outside a
compilation unit in anonymous namespaces, even editing my old files that did
things the 'old' way (using static linkage). Then suddenly I find this in the
KDE developer faq:

Q: 2.24. I put some functions in anonymous namespace and someone reverted it
and made those functions static, why?
Symbols defined in a C++ anonymous namespace do NOT have internal linkage.
Anonymous namespaces only give an unique name for that translation unit and
that is it; they don't change the linkage of the symbol at all. Linkage isn't
changed on those because the second phase of two-phase name lookup ignores
functions with internal linkages. Also, entities with internal linkage cannot
be used as template arguments

Is that true? What are the implications of this? Should I now go around all
my source files and make functions/global variables declared in them static?

The FAQ is correct, but it is not answering its own question (ie, it is
not giving any reason why file static is better than anonymous
namespaces). As Ivan has pointed out, anonymous namespaces may generate
more work for the linker - on a large project like KDE this is likely
to be the reason. I'd use anonymous namespaces unless you have a good
reason not to.

 

[Asfand Yar Qazi]

The FAQ is correct, but it is not answering its own question (ie, it is
not giving any reason why file static is better than anonymous
namespaces). As Ivan has pointed out, anonymous namespaces may generate
more work for the linker - on a large project like KDE this is likely
to be the reason. I'd use anonymous namespaces unless you have a good
reason not to.

Thank you both - I think I will look at both features from now on before
deciding which to use. I think however that I'll stick to anonymous
namespaces, as processor speeds are increasing and I'm sure they more than
compensate for a bit more compilation complexity.