How are unnamed namespaces superior to the static
keyword?
-
However, unnamed namespaces are not a sufficient replacement for _namespace-static_, according to the standards committee. [There still are a few instances](http://stackoverflow.com/q/8460327/183120) where unnamed namespaces fail and only `static` works. – legends2k Dec 06 '13 at 10:31
2 Answers
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
.

- 4,660
- 5
- 27
- 40

- 353,942
- 115
- 666
- 851
-
12More generally, an unnamed namespace allows external linkage. That's what enables the local-to-translation-unit class declaration. It also allows e.g. external linkage string constant, to be used as template argument. – Cheers and hth. - Alf Dec 12 '10 at 16:18
-
10As noted by Fred Nurk on another of your answer, it seems that this `deprecated` remark was removed from the latest C++0x FCD (n3225). – Matthieu M. Jan 18 '11 at 16:30
-
"_note that use of static keyword is deprecated when declaring objects in a namespace scope (as per the Standard)._" and you think that this deprecation has **any** weight? I mean, at all. – curiousguy Nov 25 '11 at 05:37
-
2@curiousguy: As I wrote in the same line, which you probably overlooked : "*...as per the Standard*". – Nawaz Nov 25 '11 at 05:40
-
-
3@curiousguy: Even the Standard doesn't think that anymore. C++11 has removed the deprecation! – Nawaz Nov 25 '11 at 06:01
-
@Nawaz The idea that some historical meaning of `static` was going to be removed from C++, someday, was funny indeed (for 5 minutes). – curiousguy Nov 25 '11 at 06:09
-
45You are answering you own question and saying thanks to yourself :-o – manpreet singh Apr 24 '13 at 15:15
-
13What would be the difference from just defining the class in the cpp (no anonymous namespace, no static)? – Luchian Grigore Nov 05 '13 at 14:15
-
6@LuchianGrigore Linking troubles in case 2 `.cpp` are defining a class with the same name. – Xaqq Feb 03 '14 at 02:03
-
@einpoklum the strikeout is explained in [another question](https://stackoverflow.com/q/4726570/673852). – Ruslan Feb 23 '19 at 14:09
There's an interesting problem related to this:
Suppose you use static
keyword or unnamed namespace
to make some function internal to the module (translation unit), since this function is meant to be used internally by the module and not accessible outside of it. (Unnamed namespace
s have the advantage of making data and type definitions internal, too, besides functions).
With time the source file of the implementation of your module grows large, and you would like to split it into several separate source files, which would allow for better organizing the code, finding the definitions quicker, and to be compiled independently.
But now you face a problem: Those functions can no longer be static
to the module, because static
doesn't actually refer to the module, but to the source file (translation unit). You are forced to make them non-static
to allow them to be accessed from other parts (object files) of that module. But this also means that they are no longer hidden/private to the module: having external linkage, they can be accessed from other modules, which was not your original intention.
Unnamed namespace
wouldn't solve this problem either, because it is also defined for a particular source file (translation unit) and cannot be accessed from outside.
It would be great if one could specify that some namespace
is private
, that is, whatever is defined in it, is meant to be used internally by the module it belongs to. But of course C++ doesn't have such concept as "modules", only "translation units", which are tightly bound to the source files.

- 14,009
- 7
- 43
- 43
-
3It would be a hack and a limited solution anyway, but you could include the cpp file(s) with the internal static or namespaced functions into your 'main' cpp files. Then exclude these 'satellite' cpp file(s) from build and you are done. The only problem if you have two or more 'main' cpp files and they both want to use that cool function from one of the 'satellite' cpp files... – Sergey Sep 24 '14 at 23:49
-
isn't using inheritance with private/ protected/ public with static functions the solution? – Ali Mar 13 '18 at 15:31
-
1