Blog 3 min read

5 Common Reasons for Using Namespaces in C++ Projects

Share this article
5 Common Reasons for Using Namespaces in C++ Projects

Namespaces were introduced into the C++ standard in 1995, and they are usually defined like this:

A namespace defines a new scope and provides a way to avoid name collisions.

Namespaces in C++ are most often used to avoid naming collisions. Although namespaces are used extensively in recent C++ code, most older code does not use this facility. 

After exploring the source code of many C++ projects, here are some common reasons for using namespaces in these projects.

1. Avoid name collisions.

As mentioned above, this is the most common reason. In this case, their use primarily benefits the compiler; it does not necessarily make the code more readable or maintainable for developers.

2. Modularize the application

Modern C++ libraries use namespaces extensively to modularize their codebase, and they use the “namespace-by-feature” approach. Namespace-by-feature uses namespaces to reflect the feature set. It places all items related to a single feature (and only that feature) into a single namespace. This results in namespaces with high cohesion and high modularity, and with minimal coupling between namespaces. Items that work closely together are placed next to each other.

Boost is the best example of grouping by feature; it contains thousands of namespaces, each used to group a specific feature.

3. Anonymous namespace.

An unnamed namespace provides an alternative to global static variables. The anonymous namespace is accessible only within the file in which it is declared.

4. Workaround for the enum issue.

“Traditional” enums in C++ export their enumerators into the surrounding scope, which can lead to name collisions if two different enums in the same scope define enumerators with the same name.

In a large project, there is no guarantee that two distinct enums will not use the same enumerator name. This issue was resolved in C++11 using enum class, which implicitly scopes the enum values within the enum's name.

Before C++11, a common workaround was to declare an enum inside a namespace. For example, instead of declaring an enum like this:

enum status{
  status_ok,
  status_error
};

it could be declared inside a namespace:

namespace status{
       enum status{
         ok,
          error
  };
}

Many C++ projects use this trick; for example, the Unreal Engine source code uses this technique widely.

5. Hiding details by convention

For templated libraries where the code is implemented in header files, it is useful to indicate to library users that certain types are implementation details and should not be used directly. In C#, the “internal” keyword serves this purpose, but in C++ there is no equivalent way to hide public types from library users.

A common idiom in modern C++, pioneered by the developers of the Boost libraries, is to separate symbols that form part of the implementation of your module (that is, those that don't form part of the public API) but that have to be publicly available into a separate sub-namespace, by convention named detail.

For example, the Boost.Math documentation states that:

Functions not intended for use by applications are in boost::math::detail.
Share this article