Anonymous namespaces: Are they really that great?

Question

I have been using the static keyword a long time for defining internal linkage. Later, I switched to the C++ style of wrapping local things in anonymous namespaces.

Answer 1

Apart from the very valid points noted by Steve I see other very important aspects in anonymous namespaces that make them superior to static functions: Locality, ease of refactoring and information hiding.

Assume you have one or two class function that require several other helper functions which are quite specific but do not use class members. If you stick with Robert C. Martin (Functions should be small and serve one well defined purpose) you will often find that large functions can be refactored into smaller ones although these smaller ones might in the beginning only be used in the former big function.

So what Options do you have:

1. Make a new (perhaps private) class immediately:

   This entails quite a lot of typing might be overkill and -lets face it- everybody is sometimes lazy or in a hurry.

2. Generate private static functions or non-member functions:

   Both entails editing the header file and the cpp file if you do it properly, so still a little burden that might interrupt your workflow more than necessary and generates code that unnecessarily clutters your header file, might necessitate forward declarations or even additional includes in your header.

3. Anonymous namespace:

   You have a helper function that does not need member access and serves one purpose -> Put it there and write this function close to the class methods where it will be used. This is by large my preferred one:It's quick and it does not clutter the header file. The namespace clearly states: this is not used by anything else than this cpp. No friend will use it and no library user will ever know it's existence. You can hardly be more obvious and often this paradigm will lead to cleaner function design which is few input parameters and only one output modified. Further you have function locality: Define just before primary use. While this might be a drawback I find it quite help ful when browsing the implementations of large classes. Another advantage is constants that span several functions but are not really interesting for a library user. Put them in the namespace as well, best in the same with the functions that use them. If it turns out later that you need the constants and the functions elsewhere, transform the whole into a class, its already neatly packed.

Disclaimer: Many people might argue that the use of a pimpl is by far cleaner. This is just my personal opinion.