Should I be doing anything to help manage linker namespace pollution WRT internal-use classes?
<p>In a complex library or framework, there are obviously times when classes are needed purely internally, to implement higher level functionality.</p>

<p>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.</p>

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

<p>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.</p>

<p>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.</p>

<p>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 <code>include</code> folder that holds the header files users will <code>#include</code>.</p>

<p>The symbols are still visible in the object library, though.</p>

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