Unnamed/Anonymous Namespaces Vs. Static Functions

Unnamed/anonymous namespaces vs. static functions

The C++ Standard reads in section 7.3.1.1 Unnamed namespaces, paragraph 2:

The use of the static keyword is
deprecated when declaring objects in a
namespace scope, the unnamed-namespace
provides a superior alternative.

Static only applies to names of objects, functions, and anonymous unions, not to type declarations.

Edit:

The decision to deprecate this use of the static keyword (affecting visibility of a variable declaration in a translation unit) has been reversed (ref). In this case using a static or an unnamed namespace are back to being essentially two ways of doing the exact same thing. For more discussion please see this SO question.

Unnamed namespace's still have the advantage of allowing you to define translation-unit-local types. Please see this SO question for more details.

Credit goes to Mike Percy for bringing this to my attention.

Why an unnamed namespace is a superior alternative to static? [duplicate]

• As you've mentioned, namespace works for anything, not just for functions and objects.
• As Greg has pointed out, static means too many things already.
• Namespaces provide a uniform and consistent way of controlling visibility at the global scope. You don't have to use different tools for the same thing.
• When using an anonymous namespace, the function/object name will get mangled properly, which allows you to see something like "(anonymous namespace)::xyz" in the symbol table after de-mangling, and not just "xyz" with static linkage.
• As pointed out in the comments below, it isn't allowed to use static things as template arguments, while with anonymous namespaces it's fine.
• More? Probably, but I can't think of anything else right now.

Static and anonymous namespace [duplicate]

It looks redundant to me -- either being declared static or being in an anonymous namespace means it has internal linkage.

§3.5/3:

A name having namespace scope (3.3.6) has internal linkage if it is the name of:

— a variable, function or function template that is explicitly declared static;

§3.5/4:

[...] An unnamed namespace or a namespace declared directly or indirectly within an unnamed namespace has internal linkage. [...] A name having namespace scope that has not
been given internal linkage above has the same linkage as the enclosing namespace if it is the name of

— a variable; or

— a function; or

So, as it is right now, it has internal linkage because it's explicitly declared static. If it wasn't explicitly declared static, it would have internal linkage because it's declared inside an unnamed namespace. Same effect either way.

Note that here I'm replying specifically about a function -- there are a few obscure cases where there's a difference when you're dealing with the name of a type (e.g., class/struct/union), but I don't know of any such thing that applies in the case of a function.

As far as what internal linkage really means, that's one of those places the standard is actually quite direct and clear. It's probably best to quote the definitions of all three possibilities (§3.5/2):

1. When a name has external linkage, the entity it denotes can be referred to by names from scopes of other translation units or from other scopes of the same translation unit.
2. When a name has internal linkage, the entity it denotes can be referred to by names from other scopes in the same translation unit.
3. When a name has no linkage, the entity it denotes cannot be referred to by names from other scopes.

Note that the italics above match those in the standard, which is its way of saying that these sentences define what those phrases mean throughout the rest of the standard.

Superiority of unnamed namespace over static?

You're basically referring to the section §7.3.1.1/2 from the C++03 Standard,

The use of the static keyword is
deprecated when declaring objects in a
namespace scope; the
unnamed-namespace provides a superior
alternative.

Note that this paragraph was already removed in C++11. static functions are per standard no longer deprecated!

Nonetheless, unnamed namespace's are superior to the static keyword, primarily because the keyword static applies only to the variables declarations and functions, not to the user-defined types.

The following code is valid in C++:

//legal code
static int sample_function() { /* function body */ }
static int sample_variable;

But this code is NOT valid:

//illegal code
static class sample_class { /* class body */ };
static struct sample_struct { /* struct body */ };

So the solution is, unnamed (aka anonymous) namespace, which is this:

//legal code
namespace 
{  
     class sample_class { /* class body */ };
     struct sample_struct { /* struct body */ };
}

Hope it explains that why unnamed namespace is superior to static.

Also, note that use of static keyword is deprecated when declaring objects in a namespace scope (as per the Standard).

Is there any diference between defining static function inside anonymous namespace and outside?

Yes, there is a difference.

First, let's be precise, even to the point of being pedantic:
the names exist everywhere. The distinction is:

• If a symbol is declared static (at namespace scope), it has
  internal linkage, which means that the same name in a different
  translation unit refers to a different entity.

• An unnamed namespace generates a namespace whose name is
  unique to the translation unit. The symbol still has external
  linkage (provided it is not static), but there's no way you can
  name it in another translation unit.

The main difference involves templates. At least until C++11
(and maybe still, I haven't checked), any entity used to
instantiate a template must have external linkage. So you could
not instantiate a template on something declared static, or
which implicitly had internal linkage.

Why are unnamed namespaces used and what are their benefits?

Unnamed namespaces are a utility to make an identifier translation unit local. They behave as if you would choose a unique name per translation unit for a namespace:

namespace unique { /* empty */ }
using namespace unique;
namespace unique { /* namespace body. stuff in here */ }

The extra step using the empty body is important, so you can already refer within the namespace body to identifiers like ::name that are defined in that namespace, since the using directive already took place.

This means you can have free functions called (for example) help that can exist in multiple translation units, and they won't clash at link time. The effect is almost identical to using the static keyword used in C which you can put in in the declaration of identifiers. Unnamed namespaces are a superior alternative, being able to even make a type translation unit local.

namespace { int a1; }
static int a2;

Both a's are translation unit local and won't clash at link time. But the difference is that the a1 in the anonymous namespace gets a unique name.

Read the excellent article at comeau-computing Why is an unnamed namespace used instead of static? (Archive.org mirror).

Why are anonymous namespaces not a sufficient replacement for namespace-static, according to the standards committee?

This is a more in-depth explanation.

Although 7.3.1.1 [namespace.unnamed] states that the use of the static keyword for declaring variables in namespace scope is deprecated because the unnamed namespace provides a superior alternative, it is unlikely that the feature will be removed at any point in the foreseeable future, especially in light of C compatibility concerns. The Committee should consider removing the deprecation.

One issue I know is that anonymous namespaces can't specialize templates outside of the namespace block. This is why inline namespace was introduced, although static works too. Also, static plays much nice with macros.

Are static or unnamed namespace still useful when header and implementation are separated?

Keeping a definition in implementation file does not make it private in any sense. Any other header or implementation file can declare that function and use it. It's not always a bad thing - I used parts of private implementations of libraries when I really needed it (but I do not recommend doing that).

The worse part of having such not-so-private implementation is its potential for One Definition Rule violation. ODR states that every* function or variable must have exactly one definition in the whole program. If there is more than one definition, behaviour is undefined**.

This means that when you have your not-so-private implementation in your file and nobody knows about it, they can unknowingly write a function with the same name and arguments and get an ODR violation.

It would be a good practice to use static or anonymous namespace for all free functions that should be limited to a single file. Functions that need to be used from other files cannot use this strategy, so to limit the risk of ODR violations you should use descriptive names and perhaps (named) namespaces. Just make sure you don't overuse namespaces.

---

Note: using anonymous namespaces doesn't make sense in header files. Anonymous namespace limits the scope of its content to the translation unit in which it exists, but header files are copied and pasted into (potentially) multiple TUs. The one use of anonymous namespaces is in header-only libraries, as described in this question - it allows to create global objects in header file without ODR violation (but at a cost that each TU has its own copy of that variable).

---

*except for template functions, inline functions, functions defined in class definition and a couple more. Even then, all definitions must be exactly the same.

**When I encountered it once, linker used random definition, whichever it saw at that moment. Hilarity and long debugging sessions ensued.

Why should types be put in unnamed namespaces?

Where do you want to put local types other than the unnamed namespace? Types can't have a linkage specifier like static. If they are not publicly known, e.g., because they are declared in a header, there is a fair chance that names of local types conflict, e.g., when two translation units define types with the same name. In that case you'd end up with an ODR violation. Defining the types inside an unnamed namespace eliminates this possibility.

To be a bit more concrete. Consider you have

// file demo.h
int foo();
double bar();

// file foo.cpp
struct helper { int i; };
int foo() { helper h{}; return h.i; }

// file bar.cpp
struct helper { double d; }
double bar() { helper h{}; return h.d; }

// file main.cpp
#include "demo.h"
int main() {
     return foo() + bar();
}

If you link these three translation units, you have mismatching definitions of helper from foo.cpp and bar.cpp. The compiler/linker is not required to detect these but each type which is used in the program needs to have a consistent definition. Violating this constraints is known as violation of the "one definition rule" (ODR). Any violation of the ODR rule results in undefined behavior.

Given the comment it seems a bit more convincing is needed. The relevant section of the standard is 3.2 [basic.def.odr] paragraph 6:

There can be more than one definition of a class type (Clause 9), enumeration type (7.2), inline function with external linkage (7.1.2), class template (Clause 14), non-static function template (14.5.6), static data member
of a class template (14.5.1.3), member function of a class template (14.5.1.1), or template specialization for which some template parameters are not specified (14.7, 14.5.5) in a program provided that each definition appears in a different translation unit, and provided the definitions satisfy the following requirements. Given such an entity named D defined in more than one translation unit, then each definition of D shall consist of the same sequence of tokens; and
[...]

There are plenty of further constraints but "shall consist of the same sequence of tokens" is clearly sufficient to rule out e.g. the definitions in the demo above from being legal.

---

Related Topics