How are unnamed namespaces superior to the static keyword? [duplicate]

Question

How are unnamed namespaces superior to the static keyword?

Overarm

However, unnamed namespaces are not a sufficient replacement for namespace-static, according to the standards committee. There still are a few instances where unnamed namespaces fail and only static works. – Virga

Answer 1

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

Overarm

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. – Sheedy

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). – Aniakudo

"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. – Fallal

@curiousguy: As I wrote in the same line, which you probably overlooked : "...as per the Standard". – Overarm

@Nawaz I take that as a "no". – Fallal

@curiousguy: Even the Standard doesn't think that anymore. C++11 has removed the deprecation! – Overarm

@Nawaz The idea that some historical meaning of static was going to be removed from C++, someday, was funny indeed (for 5 minutes). – Fallal

You are answering you own question and saying thanks to yourself :-o – Glyph

What would be the difference from just defining the class in the cpp (no anonymous namespace, no static)? – Jean

@LuchianGrigore Linking troubles in case 2 .cpp are defining a class with the same name. – Durrace

@einpoklum the strikeout is explained in another question. – Malefic

Answer 2

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.

Instrumental

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... – Christinachristine

isn't using inheritance with private/ protected/ public with static functions the solution? – Card

C++20 introduces modules, which solves you problem. – Palaeo