Question

In a complex library or framework, there are obviously times when classes are needed purely internally, to implement higher level functionality.

Often these internals are tightly coupled to how the internals work, so there is no point in making them available to users – all they could do with them is to try to tamper with your private internals.

At the same time, some of these things are quite large – easily large enough to require their own separate header and body source files.

If you have a small class within a single file, you can wrap it in an anonymous namespace, and a well-behaved compiler will not include symbols related to that class in the object file. The issue of namespace pollution is completely avoided.

As soon as the class is separately compiled, however, this cannot work – we need to link our other internal implementation code to this object file, so it must contain the relevant symbols.

As the header file is intended for internal use only, it should probably live in the same folder as all the body source files, as opposed to some separate include folder that holds the header files users will #include.

The symbols are still visible in the object library, though.

Is this a real problem, or an imaginary one? What (if anything) should I be doing to manage this form of namespace pollution?

Answer 1

I usually put such identifiers into a details namespace:

namespace some_component {
  namespace details {
    class helper { ... };
  }
}

some_component::details::helper is obviously an implementation detail.