6

I keep seeing code like this everywhere in my company:

namespace {

const MAX_LIMIT = 50;
const std::string TOKEN = "Token";

}

I am confused as of why you need an anonymous namespace here. On one hand, you want a local translation unit for MAX_LIMIT AND TOKEN. But that is already achieved without the anonymous namespace due to the const. static const and simple const both achieve local translation unit.

On the other hand, you don't have naming clashes if somewhere in your file you have a variable named the same.

int foo()
{
std::string TOKEN = "MyToken"; // Clash! ::TOKEN vs TOKEN can be used.
}

That would justify the anonymous namespace. But how often you you need a variable name in your function that is actually taken already by a const variable declared outside your function? My answer is never. So in practice, for me the unnamed namespace is not needed. Any hints?

FCR
  • 1,103
  • 10
  • 25
  • 3
    I'd say consistency : this `const` rule only applies to integral types. – Quentin May 12 '16 at 09:18
  • 6
    @Quentin Huh? `const` at namespace scope has internal linkage unless marked `extern`, for all types – M.M May 12 '16 at 09:19
  • @M.M My bad ! I don't know where I recalled that from, but I was pretty sure of it, too. At least I'm not alone :D – Quentin May 12 '16 at 09:23
  • maybe something to do with how in C++03, static const class members with initializer had to be integers – M.M May 12 '16 at 09:26
  • 2
    Consistency. I suspect your company has several points in its coding standard that are strictly unnecessary for a compiler but are useful for humans. – molbdnilo May 12 '16 at 09:30
  • 3
    So if simple const has internal linkage then why would someone make a variable static const ? Is there no difference between simple const and static const? – Jerry Jeremiah May 12 '16 at 09:32
  • A couple years back, the standard deprecated the static keyword for declaring variables in namespace scope, but then it changed its mind. An anonymous namespace was supposed to be better because it could also restrict type/class definitions. Somebody at your company probably decided this was a great idea before all the excitement died down. See these topics: From 2010:http://stackoverflow.com/questions/4422507/superiority-of-unnamed-namespace-over-static and From 2011:http://stackoverflow.com/questions/4726570/deprecation-of-the-static-keyword-no-more – Christopher Oicles May 12 '16 at 09:43
  • Thanks! The problem is that in that anonymous namespaced, not user define type is ever declared/defined :( – FCR May 12 '16 at 09:47

3 Answers3

5

The namespace is redundant as you explain. You could remove the namespace { and matching } .

One difference is that you could have distinct names ::TOKEN and unnamed_namespace::TOKEN. But that probably just adds confusion and it'd be better to get a compilation error.

Not sure what the second half of your post is about, local variable TOKEN shadows both ::TOKEN and unnamed_namespace::TOKEN. So the change would make no difference to that case.

M.M
  • 138,810
  • 21
  • 208
  • 365
3

In this particular case, the namespace is indeed redundant, because the const namespace scope variables indeed have internal linkage by default.

Consider the possibility of changing the code later. Perhaps one of the variables shouldn't be const after all. But making it non-const also changes the default linkage. The anonymous namespace would keep the internal linkage even after such change. In other words, the anon namespace separates the concerns over constness and the linkage. Whether that's a good thing, depends on the context.

Note that same thing can be achieved by using static keyword. Since this has exactly the same effect as the anon namespace, the choice is mostly aesthetic and therefore opinion based.

An argument for using anon namespaces instead of static could be consistency. You cannot define types with internal linkage with static. Since some internal symbols (types) cannot be defined outside an anonymous namespace, you could have a convention to define all internal symbols in an anonymous namespace. Of course, such convention would be - as conventions typically are - a matter of taste.

Your second counter argument seems to be arguing against a difference that doesn't exist. The anonymous namespace makes no difference to name hiding within function scope.

eerorika
  • 232,697
  • 12
  • 197
  • 326
0

Arguably it improves clarity. Having an anonymous namespace says much more clearly "this code is implementation detail for this compilation unit alone, not intended as part of the unit's interface". Because you have to use anonymous namespaces for local classes or structures in this way anyway (no other way to localize them), it is reasonable to encapsulate all of your local constructs in this way.

Smeeheey
  • 9,906
  • 23
  • 39