diff options
Diffstat (limited to 'libstdc++-v3/docs/html/17_intro/howto.html')
| -rw-r--r-- | libstdc++-v3/docs/html/17_intro/howto.html | 599 |
1 files changed, 397 insertions, 202 deletions
diff --git a/libstdc++-v3/docs/html/17_intro/howto.html b/libstdc++-v3/docs/html/17_intro/howto.html index d3bd6dfe393..3e1bba08acb 100644 --- a/libstdc++-v3/docs/html/17_intro/howto.html +++ b/libstdc++-v3/docs/html/17_intro/howto.html @@ -34,123 +34,309 @@ <hr /> <h1>Contents</h1> <ul> - <li><a href="#2.1">Header Files</a></li> - <li><a href="#5">Implementation specific behavior</a></li> + <li><a href="#2.0">Header Files</a></li> + <li><a href="#3.0">Namespaces</a></li> <li><a href="#6">Macros</a></li> - <li><a href="#3">Multithreading</a></li> + <li><a href="#5">Implementation specific behavior</a></li> + <li><a href="#7">Multithreading</a></li> </ul> <hr /> <!-- ####################################################### --> -<h2><a name="2.1">Header Files</a></h2> - <p>The C++ standard specifies 50 header files that must be +<h2><a name="2.0">Header Files</a></h2> + <p>The C++ standard specifies the entire set of header files that must be available to all hosted implementations. Actually, the word "files" is a misnomer, since the contents of the headers don't necessarily have to be in any kind of external file. The - only rule is that when one <code>#include</code>'s a certain header, the - contents of that header, as defined by the Standard, become + only rule is that when one <code>#include</code>'s a header, the + contents of that header become available, no matter how. </p> -<p>C++98/03 include files: +<p>That said, in practice files are used.</p> + +<p> There are two main types of include files: header files related to +a specific version of the ISO C++ standard (called Standard Headers), +and all others (TR1, C++ ABI, and Extensions).</p> + +<p>Two dialects of standard headers are supported, corresponding to +the 1998 standard as updated for 2003, and the draft of the upcoming +200x standard. +</p> + +<p>C++98/03 include files. These are available in the default compilation mode, ie <code>-std=c++98</code> or <code>-std=gnu++98</code>. </p> -<pre> -C++ Library Headers -algorithm ios new stack -bitset iosfwd numeric stdexcept -complex iostream ostream streambuf - istream queue string -deque iterator -exception limits typeinfo -fstream list set -functional locale map -iomanip memory sstream - -C++ Headers for C Library Facilities -cassert cfloat cmath cstddef -ccomplex csetjmp cstdio ctime -cctype ciso646 csignal -cerrno climits cstdarg cstdlib cwchar - clocale cstring cwctype -</pre> -<p>C++0x include files: +<center><table border="1"><caption>C++98 Library Headers</caption> +<tr><td><algorithm></td><td><iomanip></td><td><list></td><td><ostream></td><td><streambuf></td></tr> +<tr><td><bitset></td><td><ios></td><td><locale></td><td><queue></td><td><string></td></tr> +<tr><td><complex></td><td><iosfwd></td><td><map></td><td><set></td><td><typeinfo></td></tr> +<tr><td><deque></td><td><iostream></td><td><memory></td><td><sstream></td><td><utility></td></tr> +<tr><td><exception></td><td><istream></td><td><new></td><td><stack></td><td><valarray></td></tr> +<tr><td><fstream></td><td><iterator></td><td><numeric></td><td><stdexcept></td><td><vector></td></tr> +<tr><td><functional></td><td><limits></td></tr> +</table></center> + +<p></p> + +<center><table border="1"><caption>C++98 Headers for C Library Facilities</caption> +<tr><td><cassert></td><td><ciso646></td><td><csetjmp></td><td><cstdio></td><td><ctime></td></tr> +<tr><td><cctype></td><td><climits></td><td><csignal></td><td><cstdlib></td><td><cwchar></td></tr> +<tr><td><cerrno></td><td><clocale></td><td><cstdarg></td><td><cstring></td><td><cwctype></td></tr> +<tr><td><cfloat></td><td><cmath></td><td><cstddef></td></tr> +</table></center> + +<p>C++0x include files. These are only available in C++0x compilation mode, ie <code>-std=c++0x</code> or <code>-std=gnu++0x</code>. </p> + +<center><table border="1"><caption>C++0x Library Headers</caption> +<tr><td><algorithm></td><td><iomanip></td><td><locale></td><td><regex></td><td><tuple></td></tr> +<tr><td><array></td><td><ios></td><td><map></td><td><set></td><td><typeinfo></td></tr> +<tr><td><bitset></td><td><iosfwd></td><td><memory></td><td><sstream></td><td><type_traits></td></tr> +<tr><td><complex></td><td><iostream></td><td><new></td><td><stack></td><td><unordered_map></td></tr> +<tr><td><deque></td><td><istream></td><td><numeric></td><td><stdexcept></td><td><unordered_set></td></tr> +<tr><td><exception></td><td><iterator></td><td><ostream></td><td><streambuf></td><td><utility></td></tr> +<tr><td><fstream></td><td><limits></td><td><queue></td><td><string></td><td><valarray></td></tr> +<tr><td><functional></td><td><list></td><td><random></td><td><system_error></td><td><vector></td></tr> +</table></center> + +<p></p> + +<center><table border="1"><caption>C++0x Headers for C Library Facilities</caption> +<tr><td><cassert></td><td><cfloat></td><td><cmath></td><td><cstddef></td><td><ctgmath></td></tr> +<tr><td><ccomplex></td><td><cinttypes></td><td><csetjmp></td><td><cstdint></td><td><ctime></td></tr> +<tr><td><cctype></td><td><ciso646></td><td><csignal></td><td><cstdio></td><td><cuchar></td></tr> +<tr><td><cerrno></td><td><climits></td><td><cstdarg></td><td><cstdlib></td><td><cwchar></td></tr> +<tr><td><cfenv></td><td><clocale></td><td><cstdbool></td><td><cstring></td><td><cwctype></td></tr> +</table></center> + + +<p>In addition, TR1 includes as: +</p> + +<center><table border="1"><caption>TR1 Library Headers</caption> +<tr><td><tr1/array></td><td><tr1/memory></td><td><tr1/regex></td><td><tr1/type_traits></td><td><tr1/unordered_set></td></tr> +<tr><td><tr1/complex></td><td><tr1/random></td><td><tr1/tuple></td><td><tr1/unordered_map></td><td><tr1/utility></td></tr> +<tr><td><tr1/functional></td></tr> +</table></center> + +<p></p> + +<center><table border="1"><caption>TR1 Headers for C Library Facilities</caption> +<tr><td><tr1/cmath></td><td><tr1/cfloat></td><td><tr1/cstdarg></td><td><tr1/cstdio></td><td><tr1/ctime></td></tr> +<tr><td><tr1/ccomplex></td><td><tr1/cinttypes></td><td><tr1/cstdbool></td><td><tr1/cstdlib></td><td><tr1/cwchar></td></tr> +<tr><td><tr1/cfenv></td><td><tr1/climits></td><td><tr1/cstdint></td><td><tr1/ctgmath></td><td><tr1/cwctype><td></tr> +</table></center> + +<p>Also included are files for the C++ ABI interface: +</p> +<center><table border="1"><caption>C++ ABI Headers</caption> +<tr><td><cxxabi.h></td><td><cxxabi_forced.h></td></tr> +</table></center> + +<p>And a large variety of extensions. +</p> + +<center><table border="1"><caption>Extension Headers</caption> +<tr><td><ext/algorithm></td><td><ext/debug_allocator.h></td><td><ext/mt_allocator.h></td><td><ext/pod_char_traits.h></td><td><ext/stdio_sync_filebuf.h></td></tr> +<tr><td><ext/array_allocator.h></td><td><ext/enc_filebuf.h></td><td><ext/new_allocator.h></td><td><ext/pool_allocator.h></td><td><ext/throw_allocator.h></td></tr> +<tr><td><ext/atomicity.h></td><td><ext/functional></td><td><ext/numeric></td><td><ext/rb_tree></td><td><ext/typelist.h><td></tr> +<tr><td><ext/bitmap_allocator.h></td><td><ext/iterator></td><td><ext/numeric_traits.h></td><td><ext/rope></td><td><ext/type_traits.h></td></tr> +<tr><td><ext/codecvt_specializations.h></td><td><ext/malloc_allocator.h></td><td><ext/pb_ds/assoc_container.h></td><td><ext/slist></td><td><ext/vstring.h></td></tr> +<tr><td><ext/concurrence.h></td><td><ext/memory></td><td><ext/pb_ds/priority_queue.h></td><td><ext/stdio_filebuf.h></td></tr> +</table></center> + +<p></p> + +<center><table border="1"><caption>Extension Debug Headers</caption> +<tr><td><debug/bitset></td><td><debug/list></td><td><debug/set></td><td><debug/unordered_map></td><td><debug/vector></td></tr> +<tr><td><debug/deque></td><td><debug/map></td><td><debug/string></td><td><debug/unordered_set></td></tr> +</table></center> + +<p></p> + +<center><table border="1"><caption>Extension Parallel Headers</caption> +<tr><td><parallel/algorithm></td><td><parallel/numeric></td></tr> +</table></center> + +<hr /> +<h2><a name="2.1">Recipes for mixing headers</code></a></h2> + +<p> A few simple rules. +</p> + +<p>First, mixing different dialects of the standard headers is not +possible. It's an all-or-nothing affair. Thus, code like +</p> + <pre> -C++ Library Headers -algorithm ios new stack -array iosfwd numeric stdexcept -bitset iostream ostream streambuf -complex istream queue string -deque iterator random system_error -exception limits regex tuple -fstream list set type_traits -functional locale map typeinfo -iomanip memory sstream - -C++ Headers for C Library Facilities -cassert cfloat cmath cstddef ctgmath -ccomplex cinttypes csetjmp cstdio ctime -cctype ciso646 csignal cstdint cuchar -cerrno climits cstdarg cstdlib cwchar -cfenv clocale cstdbool cstring cwctype +#include <array> +#include <functional> </pre> -<p>In addition, TR1 includes as: +<p>Implies C++0x mode. To use the entities in <array>, the C++0x +compilation mode must be used, which implies the C++0x functionality +(and deprecations) in <functional> will be present. +</p> + +<p>Second, the other headers can be included with either dialect of +the standard headers, although features and types specific to C++0x +are still only enabled when in C++0x compilation mode. So, to use +rvalue references with <code>__gnu_cxx::vstring</code>, or to use the +debug-mode versions of <code>std::unordered_map</code>, one must use +the <code>std=gnu++0x</code> compiler flag. (Or <code>std=c++0x</code>, of course.) </p> + +<p>A special case of the second rule is the mixing of TR1 and C++0x +facilities. It is possible (although not especially prudent) to +include both the TR1 version and the C++0x version of header in the +same translation unit: +</p> + <pre> -C++ Library Headers -tr1/array, tr1/complex, tr1/functional, tr1/memory, tr1/random, -tr1/regex, tr1/tuple, tr1/type_traits, tr1/unordered_map, -tr1/unordered_set, tr1/utility - -C++ Headers for C Library Facilities -tr1/cmath, tr1/ccomplex, tr1/cfenv, tr1/cfloat, tr1/cinttypes, -tr1/climits, tr1/cstdarg, tr1/cstdbool, tr1/cstdint, tr1/cstdio, -tr1/cstdlib, tr1/ctgmath, tr1/ctime, tr1/cwchar, tr1/cwctype - -C++ Compatibility Headers for C Library Facilities -tr1/complex.h, tr1/ctype.h, tr1/float.h, tr1/limits.h, tr1/math.h, -tr1/stdarg.h, tr1/stdbool.h, tr1/stdint.h, tr1/stdio.h, tr1/stdlib.h, -tr1/tgmath.h, tr1/wchar.h, tr1/wctype.h +#include <tr1/type_traits> +#include <type_traits> </pre> +<p> Several parts of C++0x diverge quite substantially from TR1 predecessors. +</p> + + <hr /> -<h2><a name="2.2">Headers and <code>namespace std::</code></a></h2> +<h2><a name="2.2">The C Headers and <code>namespace std</code></a></h2> <p> - You should not use the C-headers (except for system-level - headers) from C++ programs. Instead, you should use a set of - headers that are named by prepending 'c' and, as usual, - omitting the extension (.h). For example, instead of using - <tt><math.h></tt>, you - should use <tt><cmath></tt>. In some cases this has - the advantage that the C++-header is more standardized than - the C-header (i.e. <tt><ctime></tt> (almost) - corresponds to either <tt><time.h></tt> or <tt><sys/time.h></tt>). - - The standard specifies that if you include the C-style header - (<tt><math.h></tt> in - this case), the symbols will be available both in the global - namespace and in namespace <code>std::</code> (but - libstdc++ does not yet have fully compliant headers) On the - other hand, if you include only the new header (i.e. <tt><cmath></tt>), the symbols - will only be defined in namespace <code>std::</code> - (and macros will be converted to inline-functions). + The standard specifies that if one includes the C-style header + (<math.h> in this case), the symbols will be available + in the global namespace and perhaps in + namespace <code>std::</code> (but this is no longer a firm + requirement.) One the other hand, including the C++-style + header (<cmath>) guarantees that the entities will be + found in namespace std and perhaps in the global namespace. </p> -<p>FIXME: this is no longer accurate.</p> - <p> - For more information on this, and for information on how the - GNU C++ implementation might reuse ("shadow") the C - library-functions, have a look at <a href="http://www.cantrip.org/cheaders.html" target="_top"> - www.cantrip.org</a>. - </p> +Usage of C++-style headers is recommended, as then +C-linkage names can be disambiguated by explicit qualification, such +as by <code>std::abort</code>. In addition, the C++-style headers can +use function overloading to provide a simpler interface to certain +families of C-functions. For instance in <cmath>, the +function <code>std::sin</code> has overloads for all the builtin +floating-point types. This means that <code>std::sin</code> can be +used uniformly, instead of a combination +of <code>std::sinf</code>, <code>std::sin</code>, +and <code>std::sinl</code>. +</p> + +<hr /> +<h2><a name="2.3">Precompiled Headers</a></h2> + +<p>There are three base header files that are provided. They can be +used to precompile the standard headers and extensions into binary +files that may the be used to speed compiles that use these headers. +</p> + + +<ul> +<li>stdc++.h +<p>Includes all standard headers. Actual content varies depending on +language dialect. +</p> +</li> + +<li>stdtr1c++.h +<p>Includes all of <stdc++.h>, and adds all the TR1 headers. +</p> +</li> + +<li>extc++.h +<p>Includes all of <stdtr1c++.h>, and adds all the Extension headers. +</p></li> +</ul> + +<p>How to construct a .gch file from one of these base header files.</p> + +<p>First, find the include directory for the compiler. One way to do +this is:</p> + +<pre> +g++ -v hello.cc + +#include <...> search starts here: + /mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0 +... +End of search list. +</pre> + + +<p>Then, create a precompiled header file with the same flags that +will be used to compile other projects.</p> + +<pre> +g++ -Winvalid-pch -x c++-header -g -O2 -o ./stdc++.h.gch /mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0/x86_64-unknown-linux-gnu/bits/stdc++.h +</pre> + +<p>The resulting file will be quite large: the current size is around +thirty megabytes. </p> + +<p>How to use the resulting file.</p> + +<pre> +g++ -I. -include stdc++.h -H -g -O2 hello.cc +</pre> + +<p>Verification that the PCH file is being used is easy:</p> + +<pre> +g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 hello.cc -o test.exe +! ./stdc++.h.gch +. /mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0/iostream +. /mnt/share/bld/H-x86-gcc.20071201include/c++/4.3.0/string +</pre> + +<p>The exclamation point to the left of the <code>stdc++.h.gch</code> listing means that the generated PCH file was used, and thus the </p> +<p></p> + +<p> Detailed information about creating precompiled header files can be found in the GCC <a href="http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html">documentation</a>. +</p> + <hr /> -<h2><a name="2.5">Namespace <code>std::</code></a></h2> +<h2><a name="3.0">Namespaces</a></h2> + + +<p> There are three main namespaces. +</p> + +<ul> +<li>std +<p>The ISO C++ standards specify that "all library entities are defined +within namespace std." This includes namepaces nested +within <code>namespace std</code>, such as <code>namespace +std::tr1</code>. +</p> +</li> +<li>abi +<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>__gnu_ +<p>Indicating one of several GNU extensions. Choices +include <code>__gnu_cxx</code>, <code>__gnu_debug</code>, <code>__gnu_parallel</code>, +and <code>__gnu_pbds</code>. +</p></li> +</ul> + +<p> A complete list of implementation namespaces (including namespace contents) is available in the generated source <a href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/namespaces.html">documentation</a>. +</p> + + +<hr /> +<h2><a name="3.1">Namespace <code>std::</code></a></h2> <p> One standard requirement is that the library components are defined @@ -167,37 +353,46 @@ should not be used in a global context, like header files. qualified name</i></span> for each library symbol (i.e. <code>std::string</code>, <code>std::cout</code>) Always can be used, and usually enhanced, by strategic use of typedefs. (In the -cases where the qualified verbage becomes unweidly.) +cases where the qualified verbiage becomes unwieldy.) </p></li> </ul></div> <hr /> -<h2><a name="2.6">Using namespace composition</a></h2> +<h2><a name="3.2">Using namespace composition</a></h2> <p> - <a href="http://gtkmm.sourceforge.net" target="_top">Gtk--</a> defines - most of its classes in namespace Gtk::. Thus, it was possible to - adapt Gtk-- to namespace std:: by using a C++-feature called +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>namespace gtk</code>. It is possible to + adapt <code>namespace gtk</code> to <code>namespace std</code> by using a C++-feature called <span class="emphasis"><i>namespace composition</i></span>. This is what happens if - you put a <span class="emphasis"><i>using</i></span>-declaration into a + a <span class="emphasis"><i>using</i></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; - class Window { ... } - } - </pre> +<pre class="programlisting"> +namespace gtk +{ + using std::string; + using std::tr1::array; + + class Window { ... }; +} +</pre> <p> In this example, <code>std::string</code> gets imported into - namespace Gtk::. The result is that you don't have to use - <code>std::string</code> in this header, but still + <code>namespace gtk</code>. The result is that use of + <code>std::string</code> inside namespace gtk can just use <code>string</code>, without the explicit qualification. + As an added bonus, <code>std::string</code> does not get imported into - the global namespace (::) unless the user does - <code>using namespace Gtk;</code> (which is not recommended - practice for Gtk--, so it is not a problem). Additionally, the - <code>using</code>-declarations are wrapped in macros that + the global namespace. Additionally, a more elaborate arrangement can be made for backwards compatibility and portability, whereby the + <code>using</code>-declarations can wrapped in macros that are set based on autoconf-tests to either "" or i.e. <code>using std::string;</code> (depending on whether the system has libstdc++ in <code>std::</code> or not). (ideas from @@ -206,7 +401,103 @@ cases where the qualified verbage becomes unweidly.) </p> <hr /> -<h2><a name="3">The Standard C++ library and multithreading</a></h2> +<h2><a name="6">Macros for libstdc++</a></h2> + + <p>All pre-processor switches and configurations are all gathered + in the file <code>c++config.h</code>, which is generated during + the libstdc++ configuration and build process, and included by + files part of the public libstdc++ API. Most of these macros + should not be used by consumers of libstdc++, and are reserved + for internal implementation use. <strong>These macros cannot be + redefined</strong>. However, a select handful of these macro + control libstdc++ extensions and extra features, or provide + versioning information for the API, and are able to be used. + </p> + + <p>All library macros begin with <code>_GLIBCXX_</code> (except for + versions 3.1.x to 3.3.x, which use <code>_GLIBCPP_</code>). + </p> + + <p>Below is the macro which users may check for library version + information. </p> + + <dl> + <dt><code>__GLIBCXX__</code></dt> <dd>The current version of + libstdc++ in compressed ISO date format, form of an unsigned + long. For details on the value of this particular macro for a + particular release, please consult this <a href="abi.html"> + document</a>.</dd> </dl> + + <p>Below are the macros which users may change with #define/#undef or + with -D/-U compiler flags. The default state of the symbol is + listed.</p> + + <p>"Configurable" (or "Not configurable") means + that the symbol is initially chosen (or not) based on + --enable/--disable options at library build and configure time + (documented <a href="../configopts.html">here</a>), with the + various --enable/--disable choices being translated to + #define/#undef). + </p> + + <p> "ABI" means that changing from the default value may + mean changing the ABI of compiled code. In other words, these + choices control code which has already been compiled (i.e., in a + binary such as libstdc++.a/.so). If you explicitly #define or + #undef these macros, the <em>headers</em> may see different code + paths, but the <em>libraries</em> which you link against will not. + Experimenting with different values with the expectation of + consistent linkage requires changing the config headers before + building/installing the library. + </p> + + <dl> + <dt><code>_GLIBCXX_DEPRECATED</code></dt> + <dd>Defined by default. Not configurable. ABI-changing. Turning this off + removes older ARM-style iostreams code, and other anachronisms + from the API. This macro is dependent on the version of the + standard being tracked, and as a result may give different results for + <code>-std=c++98</code> and <code>-std=c++0x</code>. This may + be useful in updating old C++ code which no longer meet the + requirements of the language, or for checking current code + against new language standards. </dd> + + <dt><code>_GLIBCXX_FORCE_NEW</code></dt> <dd>Undefined by + default. When defined, memory allocation and allocators controlled + by libstdc++ call operator new/delete without caching and + pooling. Configurable via + <code>--enable-libstdcxx-allocator</code>. ABI-changing. + </dd> + + + <dt><code>_GLIBCXX_CONCEPT_CHECKS</code></dt> <dd>Undefined by + default. Configurable via <code>--enable-concept-checks</code>. + When defined, performs compile-time checking on certain template + instantiations to detect violations of the requirements of the + standard. This is described in more detail <a + href="../19_diagnostics/howto.html#3">here</a>.</dd> + + <dt><code>_GLIBCXX_DEBUG</code></dt> + <dd>Undefined by default. When defined, compiles + user code using the <a href="../ext/debug.html#safe">libstdc++ debug + mode</a>. + </dd> + <dt><code>_GLIBCXX_DEBUG_PEDANTIC</code></dt> + <dd>Undefined by default. When defined while + compiling with the <a href="../ext/debug.html#safe">libstdc++ debug + mode</a>, makes the debug mode extremely picky by making the use + of libstdc++ extensions and libstdc++-specific behavior into + errors. + </dd> + <dt><code>_GLIBCXX_PARALLEL</code></dt> + <dd>Undefined by default. When defined, compiles + user code using the <a href="../ext/parallel_mode.html">libstdc++ parallel + mode</a>. + </dd> + </dl> + +<hr /> +<h2><a name="7">The Standard C++ library and multithreading</a></h2> <p>This section discusses issues surrounding the proper compilation of multithreaded applications which use the Standard C++ library. This information is GCC-specific since the C++ @@ -419,107 +710,11 @@ cases where the qualified verbage becomes unweidly.) <a href="../faq/index.html">to the FAQ</a>. </p> -<hr /> -<h2><a name="6">Macros for libstdc++</a></h2> - - <p>All pre-processor switches and configurations are all gathered - in the file <code>c++config.h</code>, which is generated during - the libstdc++ configuration and build process, and included by - files part of the public libstdc++ API. Most of these macros - should not be used by consumers of libstdc++, and are reserved - for internal implementation use. <strong>These macros cannot be - redefined</strong>. However, a select handful of these macro - control libstdc++ extensions and extra features, or provide - versioning information for the API, and are able to be used. - </p> - - <p>All library macros begin with <code>_GLIBCXX_</code> (except for - versions 3.1.x to 3.3.x, which use <code>_GLIBCPP_</code>). - </p> - - <p>Below is the macro which users may check for library version - information. </p> - - <dl> - <dt><code>__GLIBCXX__</code></dt> <dd>The current version of - libstdc++ in compressed ISO date format, form of an unsigned - long. For details on the value of this particular macro for a - particular release, please consult this <a href="abi.html"> - document</a>.</dd> </dl> - - <p>Below are the macros which users may change with #define/#undef or - with -D/-U compiler flags. The default state of the symbol is - listed.</p> - - <p>"Configurable" (or "Not configurable") means - that the symbol is initially chosen (or not) based on - --enable/--disable options at library build and configure time - (documented <a href="../configopts.html">here</a>), with the - various --enable/--disable choices being translated to - #define/#undef). - </p> - - <p> "ABI" means that changing from the default value may - mean changing the ABI of compiled code. In other words, these - choices control code which has already been compiled (i.e., in a - binary such as libstdc++.a/.so). If you explicitly #define or - #undef these macros, the <em>headers</em> may see different code - paths, but the <em>libraries</em> which you link against will not. - Experimenting with different values with the expectation of - consistent linkage requires changing the config headers before - building/installing the library. - </p> - - <dl> - <dt><code>_GLIBCXX_DEPRECATED</code></dt> - <dd>Defined by default. Not configurable. ABI-changing. Turning this off - removes older ARM-style iostreams code, and other anachronisms - from the API. This macro is dependent on the version of the - standard being tracked, and as a result may give different results for - <code>-std=c++98</code> and <code>-std=c++0x</code>. This may - be useful in updating old C++ code which no longer meet the - requirements of the language, or for checking current code - against new language standards. </dd> - - <dt><code>_GLIBCXX_FORCE_NEW</code></dt> <dd>Undefined by - default. When defined, memory allocation and allocators controlled - by libstdc++ call operator new/delete without caching and - pooling. Configurable via - <code>--enable-libstdcxx-allocator</code>. ABI-changing. - </dd> - - - <dt><code>_GLIBCXX_CONCEPT_CHECKS</code></dt> <dd>Undefined by - default. Configurable via <code>--enable-concept-checks</code>. - When defined, performs compile-time checking on certain template - instantiations to detect violations of the requirements of the - standard. This is described in more detail <a - href="../19_diagnostics/howto.html#3">here</a>.</dd> - - <dt><code>_GLIBCXX_DEBUG</code></dt> - <dd>Undefined by default. When defined, compiles - user code using the <a href="../ext/debug.html#safe">libstdc++ debug - mode</a>. - </dd> - <dt><code>_GLIBCXX_DEBUG_PEDANTIC</code></dt> - <dd>Undefined by default. When defined while - compiling with the <a href="../ext/debug.html#safe">libstdc++ debug - mode</a>, makes the debug mode extremely picky by making the use - of libstdc++ extensions and libstdc++-specific behavior into - errors. - </dd> - <dt><code>_GLIBCXX_PARALLEL</code></dt> - <dd>Undefined by default. When defined, compiles - user code using the <a href="../ext/parallel_mode.html">libstdc++ parallel - mode</a>. - </dd> - <!-- <dt><code></code></dt> <dd> </dd> --> - </dl> <p>Return <a href="#top">to top of page</a> or <a href="../faq/index.html">to the FAQ</a>. </p> |
