1*404b540aSrobert<?xml version="1.0" encoding="ISO-8859-1"?> 2*404b540aSrobert<!DOCTYPE html 3*404b540aSrobert PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 4*404b540aSrobert "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 5*404b540aSrobert 6*404b540aSrobert<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 7*404b540aSrobert<head> 8*404b540aSrobert <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> 9*404b540aSrobert <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" /> 10*404b540aSrobert <meta name="KEYWORDS" content="HOWTO, libstdc++, gcc, g++, libg++, STL" /> 11*404b540aSrobert <meta name="DESCRIPTION" content="HOWTO for libstdc++ chapter 17." /> 12*404b540aSrobert <meta name="GENERATOR" content="vi and eight fingers" /> 13*404b540aSrobert <title>libstdc++-v3 HOWTO: Chapter 17: Library Introduction</title> 14*404b540aSrobert<link rel="StyleSheet" href="../lib3styles.css" type="text/css" /> 15*404b540aSrobert<link rel="Start" href="../documentation.html" type="text/html" 16*404b540aSrobert title="GNU C++ Standard Library" /> 17*404b540aSrobert<link rel="Next" href="../18_support/howto.html" type="text/html" 18*404b540aSrobert title="Library Support" /> 19*404b540aSrobert<link rel="Copyright" href="license.html" type="text/html" /> 20*404b540aSrobert<link rel="Help" href="../faq/index.html" type="text/html" title="F.A.Q." /> 21*404b540aSrobert</head> 22*404b540aSrobert<body> 23*404b540aSrobert 24*404b540aSrobert<h1 class="centered"><a name="top">Chapter 17: Library Introduction</a></h1> 25*404b540aSrobert 26*404b540aSrobert<p>Chapter 17 is actually a list of definitions and descriptions used 27*404b540aSrobert in the following chapters of the Standard when describing the actual 28*404b540aSrobert library. Here, we use "Introduction" as an introduction 29*404b540aSrobert to the <em>GNU implementation of</em> the ISO Standard C++ Library. 30*404b540aSrobert</p> 31*404b540aSrobert 32*404b540aSrobert 33*404b540aSrobert<!-- ####################################################### --> 34*404b540aSrobert<hr /> 35*404b540aSrobert<h1>Contents</h1> 36*404b540aSrobert<ul> 37*404b540aSrobert <li><a href="#2">The Standard C++ header files</a></li> 38*404b540aSrobert <li><a href="#3">The Standard C++ library and multithreading</a></li> 39*404b540aSrobert <li><a href="#4"><code><foo></code> vs <code><foo.h></code></a></li> 40*404b540aSrobert <li><a href="porting-howto.html">Porting HOWTO</a></li> 41*404b540aSrobert <li><a href="#5">Behavior specific to libstdc++-v3</a></li> 42*404b540aSrobert <li><a href="#6">Preprocessor macros controlling the library</a></li> 43*404b540aSrobert</ul> 44*404b540aSrobert 45*404b540aSrobert<hr /> 46*404b540aSrobert 47*404b540aSrobert<!-- ####################################################### --> 48*404b540aSrobert 49*404b540aSrobert<h2><a name="2">The Standard C++ header files</a></h2> 50*404b540aSrobert <p>The Standard C++ Library specifies 50 header files that must be 51*404b540aSrobert available to all hosted implementations. Actually, the word 52*404b540aSrobert "files" is a misnomer, since the contents of the headers 53*404b540aSrobert don't necessarily have to be in any kind of external file. The 54*404b540aSrobert only rule is that when you <code>#include</code> a certain header, the 55*404b540aSrobert contents of that header, as defined by the Standard, become 56*404b540aSrobert available to you, no matter how. 57*404b540aSrobert </p> 58*404b540aSrobert <p>The names of the headers can be easily seen in 59*404b540aSrobert <a href="headers_cc.txt"><code>testsuite/17_intro/headers.cc</code></a>, 60*404b540aSrobert which is a small testbed we use to make certain that the headers 61*404b540aSrobert all compile and run. 62*404b540aSrobert </p> 63*404b540aSrobert 64*404b540aSrobert<hr /> 65*404b540aSrobert<h2><a name="3">The Standard C++ library and multithreading</a></h2> 66*404b540aSrobert <p>This section discusses issues surrounding the proper compilation 67*404b540aSrobert of multithreaded applications which use the Standard C++ 68*404b540aSrobert library. This information is GCC-specific since the C++ 69*404b540aSrobert standard does not address matters of multithreaded applications. 70*404b540aSrobert Unless explicitly prefaced, all information in this section is 71*404b540aSrobert current as of the GCC 3.0 release and all later point releases. 72*404b540aSrobert </p> 73*404b540aSrobert <p>Earlier GCC releases had a somewhat different approach to 74*404b540aSrobert threading configuration and proper compilation. Before GCC 3.0, 75*404b540aSrobert configuration of the threading model was dictated by compiler 76*404b540aSrobert command-line options and macros (both of which were somewhat 77*404b540aSrobert thread-implementation and port-specific). There were no 78*404b540aSrobert guarantees related to being able to link code compiled with one 79*404b540aSrobert set of options and macro setting with another set. For GCC 3.0, 80*404b540aSrobert configuration of the threading model used with libraries and 81*404b540aSrobert user-code is performed when GCC is configured and built using 82*404b540aSrobert the --enable-threads and --disable-threads options. The ABI is 83*404b540aSrobert stable for symbol name-mangling and limited functional 84*404b540aSrobert compatibility exists between code compiled under different 85*404b540aSrobert threading models. 86*404b540aSrobert </p> 87*404b540aSrobert <p>All normal disclaimers aside, multithreaded C++ application are 88*404b540aSrobert only supported when libstdc++ and all user code was built with 89*404b540aSrobert compilers which report (via <code> gcc/g++ -v </code>) the same thread 90*404b540aSrobert model and that model is not <em>single</em>. As long as your 91*404b540aSrobert final application is actually single-threaded, then it should be 92*404b540aSrobert safe to mix user code built with a thread model of 93*404b540aSrobert <em>single</em> with a libstdc++ and other C++ libraries built 94*404b540aSrobert with another thread model useful on the platform. Other mixes 95*404b540aSrobert may or may not work but are not considered supported. (Thus, if 96*404b540aSrobert you distribute a shared C++ library in binary form only, it may 97*404b540aSrobert be best to compile it with a GCC configured with 98*404b540aSrobert --enable-threads for maximal interchangeability and usefulness 99*404b540aSrobert with a user population that may have built GCC with either 100*404b540aSrobert --enable-threads or --disable-threads.) 101*404b540aSrobert </p> 102*404b540aSrobert <p>When you link a multithreaded application, you will probably 103*404b540aSrobert need to add a library or flag to g++. This is a very 104*404b540aSrobert non-standardized area of GCC across ports. Some ports support a 105*404b540aSrobert special flag (the spelling isn't even standardized yet) to add 106*404b540aSrobert all required macros to a compilation (if any such flags are 107*404b540aSrobert required then you must provide the flag for all compilations not 108*404b540aSrobert just linking) and link-library additions and/or replacements at 109*404b540aSrobert link time. The documentation is weak. Here is a quick summary 110*404b540aSrobert to display how ad hoc this is: On Solaris, both -pthreads and 111*404b540aSrobert -threads (with subtly different meanings) are honored. On OSF, 112*404b540aSrobert -pthread and -threads (with subtly different meanings) are 113*404b540aSrobert honored. On Linux/i386, -pthread is honored. On FreeBSD, 114*404b540aSrobert -pthread is honored. Some other ports use other switches. 115*404b540aSrobert AFAIK, none of this is properly documented anywhere other than 116*404b540aSrobert in ``gcc -dumpspecs'' (look at lib and cpp entries). 117*404b540aSrobert </p> 118*404b540aSrobert <p>See <a href="../faq/index.html#3">FAQ</a> (general overview), <a 119*404b540aSrobert href="../23_containers/howto.html#3">23</a> (containers), and <a 120*404b540aSrobert href="../27_io/howto.html#9">27</a> (I/O) for more information. 121*404b540aSrobert </p> 122*404b540aSrobert <p>The libstdc++-v3 library (unlike libstdc++-v2, all of it, not 123*404b540aSrobert just the STL) has been designed so that multithreaded 124*404b540aSrobert applications using it may be written. The first problem is 125*404b540aSrobert finding a <em>fast</em> method of implementation portable to all 126*404b540aSrobert platforms. Due to historical reasons, some of the library is 127*404b540aSrobert written against per-CPU-architecture spinlocks and other parts 128*404b540aSrobert against the gthr.h abstraction layer which is provided by gcc. 129*404b540aSrobert A minor problem that pops up every so often is different 130*404b540aSrobert interpretations of what "thread-safe" means for a 131*404b540aSrobert library (not a general program). We currently use the <a 132*404b540aSrobert href="http://www.sgi.com/tech/stl/thread_safety.html">same 133*404b540aSrobert definition that SGI</a> uses for their STL subset. However, the 134*404b540aSrobert exception for read-only containers only applies to the STL 135*404b540aSrobert components. 136*404b540aSrobert </p> 137*404b540aSrobert <p>Here is a small link farm to threads (no pun) in the mail archives 138*404b540aSrobert that discuss the threading problem. Each link is to the first 139*404b540aSrobert relevant message in the thread; from there you can use 140*404b540aSrobert "Thread Next" to move down the thread. This farm is in 141*404b540aSrobert latest-to-oldest order. 142*404b540aSrobert </p> 143*404b540aSrobert <ul> 144*404b540aSrobert <li>Our threading expert Loren gives a breakdown of 145*404b540aSrobert <a href="http://gcc.gnu.org/ml/libstdc++/2001-10/msg00024.html">the 146*404b540aSrobert six situations involving threads</a> for the 3.0 release series.</li> 147*404b540aSrobert <li><a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html"> 148*404b540aSrobert This message</a> inspired a recent updating of issues with threading 149*404b540aSrobert and the SGI STL library. It also contains some example 150*404b540aSrobert POSIX-multithreaded STL code.</li> 151*404b540aSrobert </ul> 152*404b540aSrobert <p> (A large selection of links to older messages has been removed; many 153*404b540aSrobert of the messages from 1999 were lost in a disk crash, and the few 154*404b540aSrobert people with access to the backup tapes have been too swamped with work 155*404b540aSrobert to restore them. Many of the points have been superseded anyhow.) 156*404b540aSrobert </p> 157*404b540aSrobert <p>This section will be updated as new and interesting issues come 158*404b540aSrobert to light. 159*404b540aSrobert </p> 160*404b540aSrobert <p>Return <a href="#top">to top of page</a> or 161*404b540aSrobert <a href="../faq/index.html">to the FAQ</a>. 162*404b540aSrobert </p> 163*404b540aSrobert 164*404b540aSrobert<hr /> 165*404b540aSrobert<h2><a name="4"><code><foo></code> vs <code><foo.h></code></a></h2> 166*404b540aSrobert <p>The new-style headers are fully supported in libstdc++-v3. The compiler 167*404b540aSrobert itself fully supports namespaces, including <code>std::</code>. 168*404b540aSrobert </p> 169*404b540aSrobert <p>For those of you new to ISO C++98, no, that isn't a typo, the headers 170*404b540aSrobert really have new names. Marshall Cline's C++ FAQ Lite has a good 171*404b540aSrobert explanation in 172*404b540aSrobert<a href="http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.4">item [27.4]</a>. 173*404b540aSrobert </p> 174*404b540aSrobert <p>Return <a href="#top">to top of page</a> or 175*404b540aSrobert <a href="../faq/index.html">to the FAQ</a>. 176*404b540aSrobert </p> 177*404b540aSrobert 178*404b540aSrobert<hr /> 179*404b540aSrobert<h2><a name="5">Behavior specific to libstdc++-v3</a></h2> 180*404b540aSrobert <p>The ISO standard defines the following phrase: 181*404b540aSrobert </p> 182*404b540aSrobert <blockquote><dl> 183*404b540aSrobert <dt><code>[1.3.5] implementation-defined behavior</code></dt> 184*404b540aSrobert <dd>behavior, for a well-formed program construct and correct data, that 185*404b540aSrobert depends on the implementation <strong>and that each implementation 186*404b540aSrobert shall document</strong>. 187*404b540aSrobert </dd> 188*404b540aSrobert </dl></blockquote> 189*404b540aSrobert <p>We do so here, for the C++ library only. Behavior of the compiler, 190*404b540aSrobert linker, runtime loader, and other elements of "the 191*404b540aSrobert implementation" are documented elsewhere. Everything listed in 192*404b540aSrobert Annex B, Implementation Qualities, are also part of the compiler, not 193*404b540aSrobert the library. 194*404b540aSrobert </p> 195*404b540aSrobert <p>For each entry, we give the section number of the standard, when 196*404b540aSrobert applicable. This list is probably incomplet and inkorrekt. 197*404b540aSrobert </p> 198*404b540aSrobert <p><strong>[1.9]/11 #3</strong> If <code>isatty(3)</code> is true, then 199*404b540aSrobert interactive stream support is implied. 200*404b540aSrobert </p> 201*404b540aSrobert <p><strong>[17.4.4.5]</strong> Non-reentrant functions are probably best 202*404b540aSrobert discussed in the various sections on multithreading (see above). 203*404b540aSrobert </p> 204*404b540aSrobert <!-- [17.4.4.8]/3 says any function that doesn't have an exception-spec 205*404b540aSrobert can throw whatever we want; see also its footnote. Let's list those 206*404b540aSrobert in the sections where the function itself occurs. 207*404b540aSrobert --> 208*404b540aSrobert <p><strong>[18.1]/4</strong> The type of <code>NULL</code> is described 209*404b540aSrobert <a href="../18_support/howto.html#1">here</a>. 210*404b540aSrobert </p> 211*404b540aSrobert <p><strong>[18.3]/8</strong> Even though it's listed in the library 212*404b540aSrobert sections, libstdc++-v3 has zero control over what the cleanup code hands 213*404b540aSrobert back to the runtime loader. Talk to the compiler people. :-) 214*404b540aSrobert </p> 215*404b540aSrobert <p><strong>[18.4.2.1]/5</strong> (bad_alloc),<br /> 216*404b540aSrobert <strong>[18.5.2]/5</strong> (bad_cast),<br /> 217*404b540aSrobert <strong>[18.5.3]/5</strong> (bad_typeid),<br /> 218*404b540aSrobert <strong>[18.6.1]/8</strong> (exception),<br /> 219*404b540aSrobert <strong>[18.6.2.1]/5</strong> (bad_exception): The <code>what()</code> 220*404b540aSrobert member function of class <code>std::exception</code>, and these other 221*404b540aSrobert classes publicly derived from it, simply returns the name of the 222*404b540aSrobert class. But they are the <em>mangled</em> names; you will need to call 223*404b540aSrobert <code>c++filt</code> and pass the names as command-line parameters to 224*404b540aSrobert demangle them, or call a 225*404b540aSrobert <a href="../18_support/howto.html#5">runtime demangler function</a>. 226*404b540aSrobert (The classes in <code><stdexcept></code> have constructors which 227*404b540aSrobert require an argument to use later for <code>what()</code> calls, so the 228*404b540aSrobert problem of <code>what()</code>'s value does not arise in most 229*404b540aSrobert user-defined exceptions.) 230*404b540aSrobert </p> 231*404b540aSrobert <p><strong>[18.5.1]/7</strong> The return value of 232*404b540aSrobert <code>std::type_info::name()</code> is the mangled type name (see the 233*404b540aSrobert previous entry for more). 234*404b540aSrobert </p> 235*404b540aSrobert <p><strong>[20.1.5]/5</strong> <em>"Implementors are encouraged to 236*404b540aSrobert supply libraries that can accept allocators that encapsulate more 237*404b540aSrobert general memory models and that support non-equal instances. In such 238*404b540aSrobert implementations, any requirements imposed on allocators by containers 239*404b540aSrobert beyond those requirements that appear in Table 32, and the semantics 240*404b540aSrobert of containers and algorithms when allocator instances compare 241*404b540aSrobert non-equal, are implementation-defined."</em> As yet we don't 242*404b540aSrobert have any allocators which compare non-equal, so we can't describe how 243*404b540aSrobert they behave. 244*404b540aSrobert </p> 245*404b540aSrobert <p><strong>[21.1.3.1]/3,4</strong>,<br /> 246*404b540aSrobert <strong>[21.1.3.2]/2</strong>,<br /> 247*404b540aSrobert <strong>[23.*]'s foo::iterator</strong>,<br /> 248*404b540aSrobert <strong>[27.*]'s foo::*_type</strong>,<br /> 249*404b540aSrobert <strong>others...</strong> 250*404b540aSrobert Nope, these types are called implementation-defined because you 251*404b540aSrobert shouldn't be taking advantage of their underlying types. Listing them 252*404b540aSrobert here would defeat the purpose. :-) 253*404b540aSrobert </p> 254*404b540aSrobert <p><strong>[21.1.3.1]/5</strong> I don't really know about the mbstate_t 255*404b540aSrobert stuff... see the <a href="../22_locale/howto.html">chapter 22 notes</a> 256*404b540aSrobert for what does exist. 257*404b540aSrobert </p> 258*404b540aSrobert <p><strong>[22.*]</strong> Anything and everything we have on locale 259*404b540aSrobert implementation will be described 260*404b540aSrobert <a href="../22_locale/howto.html">over here</a>. 261*404b540aSrobert </p> 262*404b540aSrobert <p><strong>[26.2.8]/9</strong> I have no idea what 263*404b540aSrobert <code>complex<T></code>'s pow(0,0) returns. 264*404b540aSrobert </p> 265*404b540aSrobert <p><strong>[27.4.2.4]/2</strong> Calling 266*404b540aSrobert <code>std::ios_base::sync_with_stdio</code> after I/O has already been 267*404b540aSrobert performed on the standard stream objects will 268*404b540aSrobert flush the buffers, and <!-- this line might go away --> 269*404b540aSrobert destroy and recreate the underlying buffer instances. Whether or not 270*404b540aSrobert the previously-written I/O is destroyed in this process depends mostly 271*404b540aSrobert on the --enable-libio choice: for stdio, if the written data is 272*404b540aSrobert already in the stdio buffer, the data may be completely safe! 273*404b540aSrobert </p> 274*404b540aSrobert <p><strong>[27.6.1.1.2]</strong>,<br /> 275*404b540aSrobert <strong>[27.6.2.3]</strong> The I/O sentry ctor and dtor can perform 276*404b540aSrobert additional work than the minimum required. We are not currently taking 277*404b540aSrobert advantage of this yet. 278*404b540aSrobert </p> 279*404b540aSrobert <p><strong>[27.7.1.3]/16</strong>,<br /> 280*404b540aSrobert <strong>[27.8.1.4]/10</strong> 281*404b540aSrobert The effects of <code>pubsetbuf/setbuf</code> are described 282*404b540aSrobert <a href="../27_io/howto.html#2">in this chapter</a>. 283*404b540aSrobert </p> 284*404b540aSrobert <p><strong>[27.8.1.4]/16</strong> Calling <code>fstream::sync</code> when 285*404b540aSrobert a get area exists will... whatever <code>fflush()</code> does, I think. 286*404b540aSrobert </p> 287*404b540aSrobert <p>Return <a href="#top">to top of page</a> or 288*404b540aSrobert <a href="../faq/index.html">to the FAQ</a>. 289*404b540aSrobert </p> 290*404b540aSrobert 291*404b540aSrobert<hr /> 292*404b540aSrobert<h2><a name="6">Preprocessor macros controlling the library</a></h2> 293*404b540aSrobert <p>Some of the semantics of the libstdc++-v3 implementation are 294*404b540aSrobert controlled by preprocessor macros, both during build/installation and 295*404b540aSrobert during compilation of user code. Many of these choices are made when 296*404b540aSrobert the library is built and installed (actually, during 297*404b540aSrobert <a href="../configopts.html">the configuration step</a>, with the 298*404b540aSrobert various --enable/--disable choices being translated to #define/#undef). 299*404b540aSrobert </p> 300*404b540aSrobert <p>All library macros begin with <code>_GLIBCPP_</code> in earlier 301*404b540aSrobert versions, and <code>_GLIBCXX_</code> in later versions. The fact that 302*404b540aSrobert these symbols start with a leading underscore should give you a clue 303*404b540aSrobert that (by default) they aren't meant to be changed by the user. :-) 304*404b540aSrobert </p> 305*404b540aSrobert <p>These macros are all gathered in the file <code>c++config.h</code>, 306*404b540aSrobert which is generated during installation. <strong>You must assume that 307*404b540aSrobert these macros cannot be redefined by your own code</strong>, unless we 308*404b540aSrobert document otherwise here. Some of the choices control code which has 309*404b540aSrobert already been compiled (i.e., libstdc++.a/.so). If you explicitly 310*404b540aSrobert #define or #undef these macros, the <em>headers</em> may see different 311*404b540aSrobert code paths, but the <em>libraries</em> which you link against will not. 312*404b540aSrobert If you want to experiment with different values, you must change the 313*404b540aSrobert config headers before building/installing the library. 314*404b540aSrobert </p> 315*404b540aSrobert <p>Below are macros which, for 3.1 and later, you may change yourself, 316*404b540aSrobert in your own code with #define/#undef or with -D/-U compiler flags. 317*404b540aSrobert The default state of the symbol is listed. "Configurable" 318*404b540aSrobert (or "Not configurable") means that the symbol is initially 319*404b540aSrobert chosen (or not) based on --enable/--disable options at configure time. 320*404b540aSrobert For 3.1 through 3.3, the prefixes are <code>_GLIBCPP_</code>. 321*404b540aSrobert </p> 322*404b540aSrobert <dl> 323*404b540aSrobert <dt><code>_GLIBCXX_DEPRECATED</code></dt> 324*404b540aSrobert <dd>Undefined by default. Not configurable. Turning this on enables 325*404b540aSrobert older ARM-style iostreams code, and other anachronisms. This may be 326*404b540aSrobert useful in updating old C++ programs which no longer meet the 327*404b540aSrobert requirements of the language. 328*404b540aSrobert </dd> 329*404b540aSrobert <!-- 330*404b540aSrobert Can this actually be turned off and still produce a working lib? Must 331*404b540aSrobert check. -pme 332*404b540aSrobert No, it can't. Hmmm. -pme 333*404b540aSrobert <dt><code>_GLIBCPP_RESOLVE_LIB_DEFECTS</code></dt> 334*404b540aSrobert <dd>Defined by default. Not configurable. The library follows 335*404b540aSrobert corrections and updates from the ISO committee, see 336*404b540aSrobert <a href="../faq/index.html#5_2">here</a> and 337*404b540aSrobert <a href="../ext/howto.html#5">here</a> for more on this feature. 338*404b540aSrobert If you have code which depends on the first version of the standard, 339*404b540aSrobert you might try undefining this macro. 340*404b540aSrobert </dd> 341*404b540aSrobert --> 342*404b540aSrobert <dt><code>_GLIBCXX_CONCEPT_CHECKS</code></dt> 343*404b540aSrobert <dd>Undefined by default. Configurable. When defined, performs 344*404b540aSrobert compile-time checking on certain template instantiations to detect 345*404b540aSrobert violations of the requirements of the standard. This is described 346*404b540aSrobert in more detail <a href="../19_diagnostics/howto.html#3">here</a>. 347*404b540aSrobert </dd> 348*404b540aSrobert <dt><code>_GLIBCXX_DEBUG</code></dt> 349*404b540aSrobert <dd>Undefined by default. Configurable. When defined, compiles 350*404b540aSrobert user code using the <a href="../debug.html#safe">libstdc++ debug 351*404b540aSrobert mode</a>. 352*404b540aSrobert </dd> 353*404b540aSrobert <dt><code>_GLIBCXX_DEBUG_PEDANTIC</code></dt> 354*404b540aSrobert <dd>Undefined by default. Configurable. When defined while 355*404b540aSrobert compiling with the <a href="../debug.html#safe">libstdc++ debug 356*404b540aSrobert mode</a>, makes the debug mode extremely picky by making the use 357*404b540aSrobert of libstdc++ extensions and libstdc++-specific behavior into 358*404b540aSrobert errors. 359*404b540aSrobert </dd> 360*404b540aSrobert <!-- 361*404b540aSrobert <dt><code></code></dt> 362*404b540aSrobert <dd> 363*404b540aSrobert </dd> 364*404b540aSrobert --> 365*404b540aSrobert </dl> 366*404b540aSrobert <p>Return <a href="#top">to top of page</a> or 367*404b540aSrobert <a href="../faq/index.html">to the FAQ</a>. 368*404b540aSrobert </p> 369*404b540aSrobert 370*404b540aSrobert 371*404b540aSrobert 372*404b540aSrobert<!-- ####################################################### --> 373*404b540aSrobert 374*404b540aSrobert<hr /> 375*404b540aSrobert<p class="fineprint"><em> 376*404b540aSrobertSee <a href="license.html">license.html</a> for copying conditions. 377*404b540aSrobertComments and suggestions are welcome, and may be sent to 378*404b540aSrobert<a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing list</a>. 379*404b540aSrobert</em></p> 380*404b540aSrobert 381*404b540aSrobert 382*404b540aSrobert</body> 383*404b540aSrobert</html> 384*404b540aSrobert 385*404b540aSrobert 386