title: Should every class have its own namespace?
body: <p>Something that has been troubling me for a while:</p>
  
  <p>The current wisdom is that types should be kept in a namespace that only
  contains functions which are part of the type's non-member interface (see <em>C++ Coding Standards</em> Sutter and Alexandrescu or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1893.pdf" rel="noreferrer">here</a>) to prevent ADL pulling in unrelated definitions.</p>
  
  <p>Does this imply that <strong>all</strong> classes must have a namespace of their own?  If
  we assume that a class may be augmented in the future by the addition of
  non-member functions, then it can never be safe to put two types in the
  same namespace as either one of them may introduce non-member functions
  that could interfere with the other.</p>
  
  <p>The reason I ask is that namespaces are becoming cumbersome for me.  I'm
  writing a header-only library and I find myself using classes names such as
  project::component::class_name::class_name.  Their implementations call
  helper functions but as these can't be in the same namespace they also have
  to be fully qualified!</p>
  
  <p><strong>Edit:</strong></p>
  
  <p>Several answers have suggested that C++ namespaces are simply a mechanism for avoiding name clashes.  This is not so. In C++ functions that take a parameter are resolved using <a href="http://en.wikipedia.org/wiki/Argument_dependent_name_lookup" rel="noreferrer">Argument Dependent Lookup</a>.  This means that when the compiler tries to find a function definition that matches the function name it will look at <strong>every function in the same namespace(s) as the type(s) of its parameter(s) when finding candidates</strong>.</p>
  
  <p>This can have unintended, unpleasant consequences as detailed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1893.pdf" rel="noreferrer">A Modest Proposal: Fixing ADL</a>.  Sutter and Alexandrescu's rule states never put a function in the same namespace as a class unless it is meant to be part of the interface of that class.  I don't see how I can obey that rule unless I'm prepared to give every class its own namespace.</p>
  
  <p>More suggestions very welcome!</p>