There are three main namespaces.

The library uses a number of inline namespaces as implementation details that are not intended for users to refer to directly, these include std::__detail, std::__cxx11 and std::_V2.

A complete list of implementation namespaces (including namespace contents) is available in the generated source documentation.

One standard requirement is that the library components are defined in namespace std::. Thus, in order to use these types or functions, one must do one of two things:

Best practice in programming suggests sequestering new data or functionality in a sanely-named, unique namespace whenever possible. This is considered an advantage over dumping everything in the global namespace, as then name look-up can be explicitly enabled or disabled as above, symbols are consistently mangled without repetitive naming prefixes or macros, etc.

For instance, consider a project that defines most of its classes in namespace gtk. It is possible to adapt namespace gtk to namespace std by using a C++-feature called namespace composition. This is what happens if a using-declaration is put into a namespace-definition: the imported symbol(s) gets imported into the currently active namespace(s). For example:

namespace gtk
{
  using std::string;
  using std::tr1::array;

  class Window { ... };
}

In this example, std::string gets imported into namespace gtk. The result is that use of std::string inside namespace gtk can just use string, without the explicit qualification. As an added bonus, std::string does not get imported into the global namespace. Additionally, a more elaborate arrangement can be made for backwards compatibility and portability, whereby the using-declarations can wrapped in macros that are set based on autoconf-tests to either "" or i.e. using std::string; (depending on whether the system has libstdc++ in std:: or not). (ideas from Llewelly and Karl Nelson)