libstdc++-v3/doc/html/manual/using_namespaces.html - gcc - Git at Google

 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Namespaces</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="using_dual_abi.html" title="Dual ABI" /><link rel="next" href="using_dynamic_or_shared.html" title="Linking" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Namespaces</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="using_dual_abi.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="using_dynamic_or_shared.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.namespaces"></a>Namespaces</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.namespaces.all"></a>Available Namespaces</h3></div></div></div><p> There are three main namespaces.
 </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>std</p><p>The ISO C++ standards specify that "all library entities are defined
 within namespace std." This includes namespaces nested
 within namespace <code class="code">std</code>, such as namespace
 <code class="code">std::chrono</code>.
 </p></li><li class="listitem"><p>abi</p><p>Specified by the C++ ABI. This ABI specifies a number of type and
 function APIs supplemental to those required by the ISO C++ Standard,
 but necessary for interoperability.
 </p></li><li class="listitem"><p>__gnu_</p><p>Indicating one of several GNU extensions. Choices
 include <code class="code">__gnu_cxx</code>, <code class="code">__gnu_debug</code>, <code class="code">__gnu_parallel</code>,
 and <code class="code">__gnu_pbds</code>.
 </p></li></ul></div><p> The library uses a number of inline namespaces as implementation
 details that are not intended for users to refer to directly, these include
 <code class="code">std::__detail</code>, <code class="code">std::__cxx11</code> and <code class="code">std::_V2</code>.
 </p><p>A complete list of implementation namespaces (including namespace contents) is available in the generated source <a class="link" href="https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/namespaces.html" target="_top">documentation</a>.
 </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.namespaces.std"></a>namespace std</h3></div></div></div><p>
       One standard requirement is that the library components are defined
       in <code class="code">namespace std::</code>. Thus, in order to use these types or
       functions, one must do one of two things:
 </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>put a kind of <span class="emphasis"><em>using-declaration</em></span> in your source
 (either <code class="code">using namespace std;</code> or i.e. <code class="code">using
 std::string;</code>) This approach works well for individual source files, but
 should not be used in a global context, like header files.
 	  </p></li><li class="listitem"><p>use a <span class="emphasis"><em>fully
 qualified name</em></span> for each library symbol
 (i.e. <code class="code">std::string</code>, <code class="code">std::cout</code>) Always can be
 used, and usually enhanced, by strategic use of typedefs. (In the
 cases where the qualified verbiage becomes unwieldy.)
 	  </p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.namespaces.comp"></a>Using Namespace Composition</h3></div></div></div><p>
 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.
 </p><p>For instance, consider a project that defines most of its classes in <code class="code">namespace gtk</code>. It is possible to
 	adapt <code class="code">namespace gtk</code> to <code class="code">namespace std</code> by using a C++-feature called
 	<span class="emphasis"><em>namespace composition</em></span>. This is what happens if
 	a <span class="emphasis"><em>using</em></span>-declaration is put into a
 	namespace-definition: the imported symbol(s) gets imported into the
 	currently active namespace(s). For example:
 </p><pre class="programlisting">
 namespace gtk
 {
   using std::string;
   using std::tr1::array;

   class Window { ... };
 }
 </pre><p>
 	In this example, <code class="code">std::string</code> gets imported into
 	<code class="code">namespace gtk</code>.  The result is that use of
 	<code class="code">std::string</code> inside namespace gtk can just use <code class="code">string</code>, without the explicit qualification.
 	As an added bonus,
 	<code class="code">std::string</code> does not get imported into
 	the global namespace.  Additionally, a more elaborate arrangement can be made for backwards compatibility and portability, whereby the
 	<code class="code">using</code>-declarations can wrapped in macros that
 	are set based on autoconf-tests to either "" or i.e. <code class="code">using
 	  std::string;</code> (depending on whether the system has
 	libstdc++ in <code class="code">std::</code> or not).  (ideas from
 	Llewelly and Karl Nelson)
 </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="using_dual_abi.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="using_dynamic_or_shared.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Dual ABI </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Linking</td></tr></table></div></body></html>
	<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Namespaces</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="using_dual_abi.html" title="Dual ABI" /><link rel="next" href="using_dynamic_or_shared.html" title="Linking" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Namespaces</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="using_dual_abi.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="using_dynamic_or_shared.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.namespaces"></a>Namespaces</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.namespaces.all"></a>Available Namespaces</h3></div></div></div><p> There are three main namespaces.
	</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>std</p><p>The ISO C++ standards specify that "all library entities are defined
	within namespace std." This includes namespaces nested
	within namespace <code class="code">std</code>, such as namespace
	<code class="code">std::chrono</code>.
	</p></li><li class="listitem"><p>abi</p><p>Specified by the C++ ABI. This ABI specifies a number of type and
	function APIs supplemental to those required by the ISO C++ Standard,
	but necessary for interoperability.
	</p></li><li class="listitem"><p>__gnu_</p><p>Indicating one of several GNU extensions. Choices
	include <code class="code">__gnu_cxx</code>, <code class="code">__gnu_debug</code>, <code class="code">__gnu_parallel</code>,
	and <code class="code">__gnu_pbds</code>.
	</p></li></ul></div><p> The library uses a number of inline namespaces as implementation
	details that are not intended for users to refer to directly, these include
	<code class="code">std::__detail</code>, <code class="code">std::__cxx11</code> and <code class="code">std::_V2</code>.
	</p><p>A complete list of implementation namespaces (including namespace contents) is available in the generated source <a class="link" href="https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/namespaces.html" target="_top">documentation</a>.
	</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.namespaces.std"></a>namespace std</h3></div></div></div><p>
	One standard requirement is that the library components are defined
	in <code class="code">namespace std::</code>. Thus, in order to use these types or
	functions, one must do one of two things:
	</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>put a kind of <span class="emphasis"><em>using-declaration</em></span> in your source
	(either <code class="code">using namespace std;</code> or i.e. <code class="code">using
	std::string;</code>) This approach works well for individual source files, but
	should not be used in a global context, like header files.
	</p></li><li class="listitem"><p>use a <span class="emphasis"><em>fully
	qualified name</em></span> for each library symbol
	(i.e. <code class="code">std::string</code>, <code class="code">std::cout</code>) Always can be
	used, and usually enhanced, by strategic use of typedefs. (In the
	cases where the qualified verbiage becomes unwieldy.)
	</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.namespaces.comp"></a>Using Namespace Composition</h3></div></div></div><p>
	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.
	</p><p>For instance, consider a project that defines most of its classes in <code class="code">namespace gtk</code>. It is possible to
	adapt <code class="code">namespace gtk</code> to <code class="code">namespace std</code> by using a C++-feature called
	<span class="emphasis"><em>namespace composition</em></span>. This is what happens if
	a <span class="emphasis"><em>using</em></span>-declaration is put into a
	namespace-definition: the imported symbol(s) gets imported into the
	currently active namespace(s). For example:
	</p><pre class="programlisting">
	namespace gtk
	{
	using std::string;
	using std::tr1::array;

	class Window { ... };
	}
	</pre><p>
	In this example, <code class="code">std::string</code> gets imported into
	<code class="code">namespace gtk</code>. The result is that use of
	<code class="code">std::string</code> inside namespace gtk can just use <code class="code">string</code>, without the explicit qualification.
	As an added bonus,
	<code class="code">std::string</code> does not get imported into
	the global namespace. Additionally, a more elaborate arrangement can be made for backwards compatibility and portability, whereby the
	<code class="code">using</code>-declarations can wrapped in macros that
	are set based on autoconf-tests to either "" or i.e. <code class="code">using
	std::string;</code> (depending on whether the system has
	libstdc++ in <code class="code">std::</code> or not). (ideas from
	Llewelly and Karl Nelson)
	</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="using_dual_abi.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="using_dynamic_or_shared.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Dual ABI </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Linking</td></tr></table></div></body></html>