title: Does using a C++ namespace increase coupling?
body: <p>I understand that a C++ library <em>should</em> use a namespace to avoid name collisions, but since I already have to:</p>
  
  <ol>
  <li><code>#include</code> the correct header (or forward declare the classes I intend to use)</li>
  <li>Use those classes by name</li>
  </ol>
  
  <p>Don't these two parameters <em>infer</em> the same information conveyed by a namespace.  Using a namespace now introduces a third parameter - the fully qualified name.  If the implementation of the library changes, there are now <em>three</em> potential things I need to change.  Is this not, by definition an increase in coupling between the library code and my code?</p>
  
  <hr>
  
  <p>For example, look at Xerces-C:  It defines a pure-virtual interface called <code>Parser</code> within the namespace <code>XERCES_CPP_NAMESPACE</code>.  I can make use of the <code>Parser</code> interface in my code by including the appropriate header file and then either importing the namespace <code>using namespace XERCES_CPP_NAMESPACE</code> or prefacing declarations/definitions with <code>XERCES_CPP_NAMESPACE::</code>.</p>
  
  <p>As the code evolves, perhaps there is a need to drop Xerces in favour of a different parser.  I'm partially "protected" from the change in the library implementation by the pure-virtual interface (even more so if I use a factory to construct my Parser), but as soon as I switch from Xerces to something else, I need to comb through my code and change all my <code>using namespace XERCES_CPP_NAMESPACE</code> and <code>XERCES_CPP_NAMESPACE::Parser</code> code.</p>
  
  <hr>
  
  <p>I ran into this recently when I refactored an existing C++ project to split-out some existing useful functionality into a library:</p>
  
  <p><strong>foo.h</strong></p>
  
  <pre><code>class Useful;  // Forward Declaration
  
  class Foo
  {
  public:
  
      Foo(const Useful&amp; u);
      ...snip...
  
  }
  </code></pre>
  
  <p><strong>foo.cpp</strong></p>
  
  <pre><code>#include "foo.h"
  #include "useful.h" // Useful Library
  
  Foo::Foo(const Useful&amp; u)
  {
      ... snip ...
  }
  </code></pre>
  
  <p>Largely out of ignorance (and partially out of laziness) at the time, the all of the functionality of <code>useful.lib</code> was placed in the global namespace.  </p>
  
  <p>As the contents of <code>useful.lib</code> grew (and more clients started to use the functionality), it was decided to move all the code from <code>useful.lib</code> into its own namespace called <code>"useful"</code>.</p>
  
  <p>The client <code>.cpp</code> files were easy to fix, just add a <code>using namespace useful</code>;</p>
  
  <p><strong>foo.cpp</strong></p>
  
  <pre><code>#include "foo.h"
  #include "useful.h" // Useful Library
  
  using namespace useful;
  
  Foo::Foo(const Useful&amp; u)
  {
      ... snip ...
  }
  </code></pre>
  
  <p>But the <code>.h</code> files were <em>really</em> labour intensive.  Instead of polluting the global namespace by putting <code>using namespace useful;</code> in the header files, I wrapped the existing forward declarations in the namespace:</p>
  
  <p><strong>foo.h</strong></p>
  
  <pre><code>namespace useful {
      class Useful;  // Forward Declaration
  }
  
  class Foo
  {
  public:
  
      Foo(const useful::Useful&amp; u);
      ...snip...
  }
  </code></pre>
  
  <p>There were dozens (<em>and dozens</em>) of files and this ended up being a major pain!  It should not have been that difficult.  Clearly I did something wrong with either the design and/or implementation.</p>
  
  <p>Although I know that library code <em>should</em> be in its own namespace, would it have been advantageous for the library code to remain in the global namespace, and instead try to manage the <code>#includes</code>?</p>