140

How are unnamed namespaces superior to the static keyword?

einpoklum
  • 86,754
  • 39
  • 223
  • 453
Nawaz
  • 327,095
  • 105
  • 629
  • 812
  • 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 Answers2

143

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).
Olivia Stork
  • 4,312
  • 4
  • 23
  • 39
Nawaz
  • 327,095
  • 105
  • 629
  • 812
  • 12
    More 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
  • @Alf : That's true. Thanks for the addition. :-) – Nawaz Dec 12 '10 at 16:23
  • 10
    As 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
  • @Nawaz I take that as a "no". – curiousguy Nov 25 '11 at 05:59
  • 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
  • 41
    You are answering you own question and saying thanks to yourself :-o – manpreet singh Apr 24 '13 at 15:15
  • 12
    What 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
10

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 namespaces 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.

SasQ
  • 11,814
  • 5
  • 39
  • 42
  • 3
    It 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
    C++20 introduces modules, which solves you problem. – L. F. Apr 22 '19 at 06:54