Skip to content

R
riscv-gcc-1
Commit 79e79067 by Benjamin Kosnik Committed by Benjamin Kosnik
Options

howto.html: Update. 

2007-12-09  Benjamin Kosnik  <bkoz@redhat.com>

	* docs/html/ext/howto.html: Update.
	* docs/html/ext/sgiexts.html: Same.
	* docs/html/ext/concurrence.html: New. Document extensions.
	* docs/html/17_intro/api.html: Move some bits...
	* docs/html/17_intro/backwards_compatibility.html: here. New. Add
	compatibility suggestions, move existing ones.
	* docs/html/17_intro/howto.html: Update info.
	* docs/html/18_support/howto.html: Tweak.
	* docs/html/faq/index.html: Update thread info.
	* docs/html/documentation.html: Add links.
	* docs/html/20_util/allocator.html: Update info.
	* include/precompiled/stdc++.h: Add C++0x includes if appropriate.
	* testsuite/17_intro/headers/c++200x/all.cc: Same.

From-SVN: r130732
parent 6e221515
Showing with 2121 additions and 739 deletions
libstdc++-v3/ChangeLog
2007-12-09 Benjamin Kosnik <bkoz@redhat.com>
* docs/html/ext/howto.html: Update.
* docs/html/ext/sgiexts.html: Same.
* docs/html/ext/concurrence.html: New. Document extensions.
* docs/html/17_intro/api.html: Move some bits...
* docs/html/17_intro/backwards_compatibility.html: here. New. Add
compatibility suggestions, move existing ones.
* docs/html/17_intro/howto.html: Update info.
* docs/html/18_support/howto.html: Tweak.
* docs/html/faq/index.html: Update thread info.
* docs/html/documentation.html: Add links.
* docs/html/20_util/allocator.html: Update info.
* include/precompiled/stdc++.h: Add C++0x includes if appropriate.
* testsuite/17_intro/headers/c++200x/all.cc: Same.
2007-12-09 Jonathan Wakely <jwakely.gcc@gmail.com> 2007-12-09 Jonathan Wakely <jwakely.gcc@gmail.com>
* testsuite/util/testsuite_allocator.h, * testsuite/util/testsuite_allocator.h,
......
libstdc++-v3/docs/html/17_intro/api.html
...@@ -5,8 +5,8 @@ ...@@ -5,8 +5,8 @@
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head> <head>
<meta name="AUTHOR" content="bkoz@gcc.gnu.org (Benjamin Kosnik), Felix Natter" /> <meta name="AUTHOR" content="bkoz@gcc.gnu.org (Benjamin Kosnik)" />
<meta name="KEYWORDS" content="C++, libstdc++, API, deprecate backward" /> <meta name="KEYWORDS" content="C++, libstdc++, API, evolution, deprecate" />
<meta name="DESCRIPTION" content="API evolution and deprecation history" /> <meta name="DESCRIPTION" content="API evolution and deprecation history" />
<meta name="GENERATOR" content="emacs and ten fingers" /> <meta name="GENERATOR" content="emacs and ten fingers" />
<title>API Evolution and Deprecation History</title> <title>API Evolution and Deprecation History</title>
...@@ -22,7 +22,7 @@ ...@@ -22,7 +22,7 @@
<p class="fineprint"><em> <p class="fineprint"><em>
The latest version of this document is always available at The latest version of this document is always available at
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/api.html"> <a href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/api.html">
http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/abi.html</a>. http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/api.html</a>.
</em></p> </em></p>
<p><em> <p><em>
...@@ -30,565 +30,260 @@ ...@@ -30,565 +30,260 @@
</em></p> </em></p>
<!-- ####################################################### --> <!-- ####################################################### -->
<hr /> <hr />
<h3 class="left"> <h3 class="left">
<a name="C++ API v1">First.</a> <a name="intro">API Evolution, Deprecation, and History of User Visible Changes</a>
</h3> </h3>
<p>2.72</p> <p> A list of user-visible changes, by release version.
<p> The first generation GNU C++ library was called libg++. It had a
working relationship with at least two kinds of dinosaur. Sadly, the
details were not pried away from the estate.
</p> </p>
<p> <h3 class="left">
<a name="3.0">3.0</a>
</h3>
<p>
Extensions moved to <code>include/ext</code>.
</p> </p>
<p>Known Issues include many of the limitations of its immediate ancestor.</p> <p>
Include files from the SGI/HP sources that pre-date the ISO standard
<h5>No <code>ios_base</code></h5> are added. These files are placed into
the <code>include/backward</code> directory and a deprecated warning
<p> At least some older implementations don't have <code>std::ios_base</code>, so you should use <code>std::ios::badbit</code>, <code>std::ios::failbit</code> and <code>std::ios::eofbit</code> and <code>std::ios::goodbit</code>. is added that notifies on inclusion (<code>-Wno-deprecated</code>
deactivates the warning.)
</p> </p>
<h5>No <code>cout</code> in <code>ostream.h</code>, no <code>cin</code> in <code>istream.h</code></h5> <p>Deprecated include &lt;backward/strstream&gt; added.</p>
<p>
In earlier versions of the standard,
<tt>&lt;fstream.h&gt;</tt>,
<tt>&lt;ostream.h&gt;</tt>
and <tt>&lt;istream.h&gt;</tt>
used to define
<code>cout</code>, <code>cin</code> and so on. ISO C++ specifies that one needs to include
<tt>&lt;iostream&gt;</tt>
explicitly to get the required definitions.
</p>
<p> Some include adjustment may be required.</p>
<p>Removal of include &lt;builtinbuf.h&gt;, &lt;indstream.h&gt;, &lt;parsestream.h&gt;, &lt;PlotFile.h&gt;, &lt;SFile.h&gt;, &lt;stdiostream.h&gt;, and &lt;stream.h&gt;.</p>
<p>This project is no longer maintained or supported, and the sources
archived. The code is considered replaced and rewritten.
</p>
<hr />
<h3 class="left"> <h3 class="left">
<a name="C++ API v1">Second.</a> <a name="3.1">3.1</a>
</h3> </h3>
<p> The second generation GNU C++ library was called libstdc++, or
libstdc++-v2. It was a separate GNU project, although reliably paired
with GCC. It spans the time between libg++ and pre-ISO C++.
</p>
<p>egcs 1.x</p>
<p>2.95</p>
<p>2.96</p>
<p>Portability Notes</p>
<p>Implementation Limitations</p>
<h5>Namespace <code>std::</code> not supported.</h5>
<p> <p>
Some care is required to support C++ compiler and or library Extensions from SGI/HP moved from <code>namespace std</code>
implementation that do not have the standard library in to <code>namespace __gnu_cxx</code>. As part of this, the following
<code>namespace std</code>. new includes are
</p> added: &lt;ext/algorithm&gt;, &lt;ext/functional&gt;, &lt;ext/iterator&gt;, &lt;ext/memory&gt;, and &lt;ext/numeric&gt;.
<p> </p>
The following sections list some possible solutions to support compilers
that cannot ignore <code>std::</code>-qualified names.
</p>
<p> First, see if the compiler has a flag for this. Namespace
back-portability-issues are generally not a problem for g++
compilers that do not have libstdc++ in <code>std::</code>, as
the compilers use <code>-fno-honor-std</code> (ignore
<code>std::</code>, <code>:: = std::</code>) by default. That
is, the responsibility for enabling or disabling
<code>std::</code> is on the user; the maintainer does not have
to care about it. This probably applies to some other compilers
as well.
</p>
<p>Second, experiment with a variety of pre-processor tricks.</p>
<p> By defining <code>std</code> as a macro, fully-qualified namespace calls become global. Volia.
<pre class="programlisting">
#ifdef WICKEDLY_OLD_COMPILER
# define std
#endif
</pre>
(thanks to Juergen Heinzl who posted this solution on gnu.gcc.help)
<p>Define a macro <code>NAMESPACE_STD</code>, which is defined to
either &quot;&quot; or &quot;std&quot; based on a compile-type
test. On GNU systems, this can be done with autotools by means of an
autoconf test (see below) for <code>HAVE_NAMESPACE_STD</code>, then
using that to set a value for the <code>NAMESPACE_STD</code> macro.
At that point, one is able to use <code>NAMESPACE_STD::string</code>,
which will evaluate to <code>std::string</code> or
<code>::string</code> (ie, in the global namespace on systems that do
not put <code>string</code> in <code>std::</code>). </p>
<p> <p>
<pre> Extensions to <code>basic_filebuf</code> introduced: <code>__gnu_cxx::enc_filebuf</code>, and <code>__gnu_cxx::stdio_filebuf</code>.
dnl @synopsis AC_CXX_HAVE_STD_NAMESPACE
dnl
dnl If the compiler supports the std namespace, define
dnl HAVE_STD_NAMESPACE.
dnl
dnl @category Cxx
dnl @author Todd Veldhuizen
dnl @author Luc Maisonobe <luc@spaceroots.org>
dnl @version 2004-02-04
dnl @license AllPermissive
AC_DEFUN([AC_CXX_HAVE_STD_NAMESPACE],
[AC_CACHE_CHECK(whether the compiler supports the std namespace,
ac_cv_cxx_have_std_namespace,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([#include <iostream>
std::istream& is = std::cin;
],[return 0;],
ac_cv_cxx_have_std_namespace=yes, ac_cv_cxx_have_std_namespace=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_have_std_namespace" = yes; then
AC_DEFINE(HAVE_STD_NAMESPACE,,[define if the compiler supports the std namespace])
fi
])
</pre>
<h5>Illegal iterator usage.</h5>
<p>
The following illustrate implementation-allowed illegal iterator
use, and then correct use. <div class="itemizedlist"><ul
type="disc"> <li><p>you cannot do
<code>ostream::operator&lt;&lt;(iterator)</code> to print the
address of the iterator =&gt; use <code>operator&lt;&lt;
&amp;*iterator</code> instead ?
</p></li>
<li><p>you cannot clear an iterator's reference
(<code>iterator = 0</code>) =&gt; use
<code>iterator = iterator_type();</code> ?
</p></li>
<li><p>
<code>if (iterator)</code> won't work any
more =&gt; use <code>if (iterator != iterator_type())</code>
?</p></li>
</ul>
<h5><code>isspace</code> from <tt>&lt;cctype&gt;</tt> is a macro
</h5>
<p> Glibc 2.0.x and 2.1.x define <tt>&lt;ctype.h&gt;</tt>
functionality as macros (isspace, isalpha etc.).
</p> </p>
<p> <p>
This implementations of libstdc++, however, keep these functions as Extensions to tree data structures added in &lt;ext/rb_tree&gt;.
macros, and so it is not back-portable to use fully qualified
names. For example:
</p> </p>
<pre> <p>
#include &lt;cctype&gt; Removal of &lt;ext/tree&gt;, moved to &lt;backward/tree.h&gt;.
int main() { std::isspace('X'); }
</pre>
<p>Results in something like this:
</p> </p>
<pre>
std:: (__ctype_b[(int) ( ( 'X' ) )] &amp; (unsigned short int) _ISspace ) ;
</pre>
<h3 class="left">
<a name="3.2">3.2</a>
</h3>
<p>Symbol versioning introduced for shared library.</p>
<p> A solution is to modify a header-file so that the compiler tells <p>Removal of include &lt;backward/strstream.h&gt;.</p>
<tt>&lt;ctype.h&gt;</tt> to define functions instead of macros:
</p>
<pre> <h3 class="left">
// This keeps isalnum, et al from being propagated as macros. <a name="3.3">3.3</a>
#if __linux__ </h3>
# define __NO_CTYPE 1 <p>Allocator changes. Change <code>__malloc_alloc</code> to <code>malloc_allocator</code> and <code>__new_alloc</code> to <code>new_allocator</code>. </p>
#endif
</pre> <p>Error handling in iostreams cleaned up, made consistent. </p>
<p>Then, include &lt;ctype.h&gt;
</p>
<h3 class="left">
<a name="3.4">3.4</a>
</h3>
<p> <p>
Another problem arises if you put a <code>using namespace std;</code> Large file support.
declaration at the top, and include <tt>&lt;ctype.h&gt;</tt>. This
will result in ambiguities between the definitions in the global
namespace (<tt>&lt;ctype.h&gt;</tt>) and the definitions in namespace
<code>std::</code> (<code>&lt;cctype&gt;</code>).
</p> </p>
<h5>No <code>vector::at</code>, <code>deque::at</code>, <code>string::at</code></h5> <p> Extensions for generic characters and <code>char_traits</code> added in &lt;ext/pod_char_traits.h&gt;.
</p>
<p> <p>
One solution is to add an autoconf-test for this: Support for <code>wchar_t</code> specializations of <code>basic_filebuf</code> enhanced to support <code>UTF-8</code> and <code>Unicode</code>, depending on host. More hosts support basic <code>wchar_t</code> functionality.
</p> </p>
<pre>
AC_MSG_CHECKING(for container::at)
AC_TRY_COMPILE(
[
#include &lt;vector&gt;
#include &lt;deque&gt;
#include &lt;string&gt;
using namespace std;
],
[
deque&lt;int&gt; test_deque(3);
test_deque.at(2);
vector&lt;int&gt; test_vector(2);
test_vector.at(1);
string test_string(&quot;test_string&quot;);
test_string.at(3);
],
[AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_CONTAINER_AT)],
[AC_MSG_RESULT(no)])
</pre>
<p> <p>
If you are using other (non-GNU) compilers it might be a good idea Support for <code>char_traits</code> beyond builtin types.
to check for <code>string::at</code> separately.
</p> </p>
<h5>No <code>std::char_traits&lt;char&gt;::eof</code></h5>
<p> <p>
Use some kind of autoconf test, plus this: Conformant <code>allocator</code> class and usage in containers. As
part of this, the following extensions are
added: &lt;ext/bitmap_allocator.h&gt;, &lt;ext/debug_allocator.h&gt;, &lt;ext/mt_allocator.h&gt;, &lt;ext/malloc_allocator.h&gt;,&lt;ext/new_allocator.h&gt;, &lt;ext/pool_allocator.h&gt;.
</p> </p>
<pre>
#ifdef HAVE_CHAR_TRAITS
#define CPP_EOF std::char_traits&lt;char&gt;::eof()
#else
#define CPP_EOF EOF
#endif
</pre>
<h5>No <code>string::clear</code></h5>
<p> <p>
There are two functions for deleting the contents of a string: Debug mode first appears.
<code>clear</code> and <code>erase</code> (the latter </p>
returns the string).
<pre class="programlisting">
void
clear() { _M_mutate(0, this-&gt;size(), 0); }
</pre>
<pre class="programlisting">
basic_string&amp;
erase(size_type __pos = 0, size_type __n = npos)
{
return this-&gt;replace(_M_check(__pos), _M_fold(__pos, __n),
_M_data(), _M_data());
}
</pre>
Unfortunately, ut <code>clear</code> is not
implemented in this version, so you should use
<code>erase</code> (which is probably faster than
<code>operator=(charT*)</code>).
</p>
<h5>Removal of <code>ostream::form</code> and
<code>istream::scan</code> extensions.</h5>
<p> These are no longer supported. Please use
<a href="#sec-stringstream" title="Using stringstreams">
stringstreams</a> instead.
</p>
<h5>No <code>basic_stringbuf</code>, <code>basic_stringstream<code></h5>
<p> <p>
Libstdc++ provides the new PCH support.
<code>i/ostringstream</code>-classes, (<tt>&lt;sstream&gt;</tt>), but for compatibility
with older implementations you still have to use
<code>i/ostrstream</code> (<tt>&lt;strstream&gt;</tt>):
<pre >
#ifdef HAVE_SSTREAM
#include &lt;sstream&gt;
#else
#include &lt;strstream&gt;
#endif
</pre>
<div class="itemizedlist"><ul type="disc">
<li><p> <code>strstream</code> is considered to be
deprecated
</p></li>
<li><p> <code>strstream</code> is limited to
<code>char</code>
</p></li>
<li><p> with <code>ostringstream</code> you don't
have to take care of terminating the string or freeing its
memory
</p></li>
<li><p> <code>istringstream</code> can be re-filled
(clear(); str(input);)
</p></li>
</ul></div>
<p>
You can then use output-stringstreams like this:
<pre >
#ifdef HAVE_SSTREAM
std::ostringstream oss;
#else
std::ostrstream oss;
#endif
oss &lt;&lt; &quot;Name=&quot; &lt;&lt; m_name &lt;&lt; &quot;, number=&quot; &lt;&lt; m_number &lt;&lt; std::endl;
...
#ifndef HAVE_SSTREAM
oss &lt;&lt; std::ends; // terminate the char*-string
#endif
// str() returns char* for ostrstream and a string for ostringstream
// this also causes ostrstream to think that the buffer's memory
// is yours
m_label.set_text(oss.str());
#ifndef HAVE_SSTREAM
// let the ostrstream take care of freeing the memory
oss.freeze(false);
#endif
</pre>
<p>
Input-stringstreams can be used similarly:
</p> </p>
<pre> <p>
std::string input; Macro guard for libstdc++ changed, from _GLIBCPP_ to _GLIBCXX_.
... </p>
#ifdef HAVE_SSTREAM
std::istringstream iss(input);
#else
std::istrstream iss(input.c_str());
#endif
int i; <p>
iss &gt;&gt; i; Extension &lt;ext/stdio_sync_filebuf.h&gt; added.
</pre> </p>
<p> One (the only?) restriction is that an istrstream cannot be re-filled: <p>
Extension &lt;ext/demangle.h&gt; added.
</p> </p>
<pre >
std::istringstream iss(numerator);
iss &gt;&gt; m_num;
// this is not possible with istrstream
iss.clear();
iss.str(denominator);
iss &gt;&gt; m_den;
</pre>
<h3 class="left">
<a name="4.0">4.0</a>
</h3>
<p> <p>
If you don't care about speed, you can put these conversions in TR1 features first appear.
a template-function:
</p> </p>
<pre >
template &lt;class X&gt;
void fromString(const string&amp; input, X&amp; any)
{
#ifdef HAVE_SSTREAM
std::istringstream iss(input);
#else
std::istrstream iss(input.c_str());
#endif
X temp;
iss &gt;&gt; temp;
if (iss.fail())
throw runtime_error(..)
any = temp;
}
</pre>
<p> Another example of using stringstreams is in <a href="../21_strings/howto.html" target="_top">this howto</a>. <p>
Extension allocator &lt;ext/array_allocator.h&gt; added.
</p> </p>
<p> There is additional information in the libstdc++-v2 info files, in <p>
particular &quot;info iostream&quot;. Extension <code>codecvt</code> specializations moved to &lt;ext/codecvt_specializations.h&gt;.
</p> </p>
<h5>Little or no wide character support</h5> <p>
Removal of &lt;ext/demangle.h&gt;.
<h5>No templatized iostreams</h5>
<h5>Thread safety issues.</h5>
<p>This project is no longer maintained or supported, and the sources
archived. The code is considered replaced and rewritten.
</p> </p>
<hr />
<h3 class="left"> <h3 class="left">
<a name="C++ API v1">Third.</a> <a name="4.1">4.1</a>
</h3> </h3>
<p> The third generation GNU C++ library is called libstdc++, or
libstdc++-v3.
</p>
<p>The subset commonly known as the Standard Template Library <p>
(chapters 23 through 25, mostly) is adapted from the final release Removal of &lt;cassert&gt; from all standard headers: now has to be explicitly included for <code>std::assert</code> calls.
of the SGI STL, with extensive changes. </p>
</p>
<p>A more formal description of the V3 goals can be found in the <p> Extensions for policy-based data structures first added. New includes,
official <a href="../17_intro/DESIGN">design document</a>. types, namespace <code>pb_assoc</code>.
</p> </p>
<p>Portability Notes</p>
<h5>Pre-ISO headers moved to backwards</h5> <p> Extensions for typelists added in &lt;ext/typelist.h&gt;.
<p> The pre-ISO C++ headers (iostream.h etc.) are available, but inclusion
generates a warning that you are using deprecated headers.
</p> </p>
<p>This compatibility layer is constructed by including the <p> Extension for policy-based <code>basic_string</code> first added: <code>__gnu_cxx::__versa_string</code> in &lt;ext/vstring.h&gt;.
standard C++ headers, and injecting any items in </p>
<code>std::</code> into the global namespace.
</p>
<p>For those of you new to ISO C++ (welcome, time travelers!), no,
that isn't a typo. Yes, the headers really have new names.
Marshall Cline's C++ FAQ Lite has a good explanation in <a
href="http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.4">item
[27.4]</a>.
</p>
<p> Some include adjustment may be required.</p>
<h5>Extension headers hash_map, hash_set moved to ext</h5> <h3 class="left">
<a name="4.2">4.2</a>
</h3>
<p> Header files <code>hash_map</code> and <code>hash_set</code> <p> Default visibility attributes applied to <code>namespace std</code>. Support for <code>-fvisibility</code>.
moved to <code>ext/hash_map</code> and <code>ext/hash_set</code>,
respectively. At the same time, all types in these files are enclosed
in <code>namespace __gnu_cxx</code>.
</p> </p>
<p>TR1 &lt;random&gt;, &lt;complex&gt;, and C compatibility headers added.</p>
<h5> <p> Extensions for concurrent programming consolidated
No <code>ios::nocreate/ios::noreplace</code>. into &lt;ext/concurrence.h&gt; and &lt;ext/atomicity.h&gt;,
</h5> including change of namespace to <code>__gnu_cxx</code> in some
cases. Added types
include <code>_Lock_policy</code>, <code>__concurrence_lock_error</code>, <code>__concurrence_unlock_error</code>, <code>__mutex</code>, <code>__scoped_lock</code>.</p>
<p> The existence of <code>ios::nocreate</code> being used for <p> Extensions for type traits consolidated
input-streams has been confirmed, most probably because the author into &lt;ext/type_traits.h&gt;. Additional traits are added
thought it would be more correct to specify nocreate explicitly. So (<code>__conditional_type</code>, <code>__enable_if</code>, others.)
it can be left out for input-streams.
</p> </p>
<p>For output streams, &quot;nocreate&quot; is probably the default, <p> Extensions for policy-based data structures revised. New includes,
unless you specify <code>std::ios::trunc</code> ? To be safe, you can types, namespace moved to <code>__pb_ds</code>.
open the file for reading, check if it has been opened, and then
decide whether you want to create/replace or not. To my knowledge,
even older implementations support <code>app</code>, <code>ate</code>
and <code>trunc</code> (except for <code>app</code> ?).
</p> </p>
<p> Extensions for debug mode modified: now nested in <code>namespace
std::__debug</code> and extensions in <code>namespace
__gnu_cxx::__debug</code>.</p>
<h5> <p> Extensions added: &lt;ext/typelist.h&gt;
No <code>stream::attach(int fd)</code>. and &lt;ext/throw_allocator.h&gt;.
</h5> </p>
<p>
Phil Edwards writes: It was considered and rejected for the ISO
standard. Not all environments use file descriptors. Of those
that do, not all of them use integers to represent them.
</p>
<p>
For a portable solution (among systems which use
filedescriptors), you need to implement a subclass of
<code>std::streambuf</code> (or
<code>std::basic_streambuf&lt;..&gt;</code>) which opens a file
given a descriptor, and then pass an instance of this to the
stream-constructor.
</p>
<p> <h3 class="left">
An extension is available that implements this. <a name="4.3">4.3</a>
<code>&lt;ext/stdio_filebuf.h&gt;</code> contains a derived class called </h3>
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/class____gnu__cxx_1_1stdio__filebuf.html"><code>__gnu_cxx::stdio_filebuf</code></a>.
This class can be constructed from a C <code>FILE*</code> or a file
descriptor, and provides the <code>fd()</code> function.
</p>
<p> <p>
For another example of this, refer to C++0X features first appear.
<a href="http://www.josuttis.com/cppcode/fdstream.html" target="_top">fdstream example</a>
by Nicolai Josuttis.
</p> </p>
<p><a href="http://gcc.gnu.org/bugzilla/buglist.cgi?cmdtype=runnamed&namedcmd=libstdc%2B%2B">Known Issues</a></p> <p>TR1 &lt;regex&gt; and &lt;cmath&gt;'s mathematical special function added.</p>
<h5>
container iterator types are not necessarily container value_type*
</h5>
<p>API History, User Visible Changes</p>
<p>3.0.0</p>
<p>3.1.0</p>
<p>3.2.0</p>
<p>3.3.0</p>
<p>3.4.0</p>
Macro guard for libstdc++ changed, from _GLIBCPP_ to _GLIBCXX_, to
accomodate a request from the C Pre Processor maintainer.
<p>4.0.0</p>
<p>4.1.0</p>
<cassert> how has to be explicitly included for <code>std::assert</code> calls.
<p>4.2.0</p>
<p>4.3.0</p>
Header streamlining.
<p>
Backward include edit. Backward include edit.
</p>
<ul>
<li> Removed: &lt;algobase.h&gt; &lt;algo.h&gt; &lt;alloc.h&gt; &lt;bvector.h&gt; &lt;complex.h&gt;
defalloc.h&gt; &lt;deque.h&gt; &lt;fstream.h&gt; &lt;function.h&gt; &lt;hash_map.h&gt; &lt;hash_set.h&gt;
hashtable.h&gt; &lt;heap.h&gt; &lt;iomanip.h&gt; &lt;iostream.h&gt; &lt;istream.h&gt; &lt;iterator.h&gt;
list.h&gt; &lt;map.h&gt; &lt;multimap.h&gt; &lt;multiset.h&gt; &lt;new.h&gt; &lt;ostream.h&gt; &lt;pair.h&gt; &lt;queue.h&gt;
rope.h&gt; &lt;set.h&gt; &lt;slist.h&gt; &lt;stack.h&gt; &lt;streambuf.h&gt; &lt;stream.h&gt; &lt;tempbuf.h&gt;
&lt;tree.h&gt; &lt;vector.h&gt;
</li>
<li> Added: &lt;hash_map&gt; and &lt;hash_set&gt;</li>
<li> Added in C++0x: &lt;auto_ptr.h&gt; and &lt;binders.h&gt;</li>
</ul>
PCH files built but not installed. <p>
Header dependency streamlining.
Namespace pb_ds moved to __gnu_pb_ds. </p>
C++OX features appear. <ul>
<li>&lt;algorithm&gt; no longer includes &lt;climits&gt;, &lt;cstring&gt;, or &lt;iosfwd&gt; </li>
<li>&lt;bitset&gt; no longer includes &lt;istream&gt; or &lt;ostream&gt;, adds &lt;iosfwd&gt; </li>
<li>&lt;functional&gt; no longer includes &lt;cstddef&gt;</li>
<li>&lt;iomanip&gt; no longer includes &lt;istream&gt;, &lt;istream&gt;, or &lt;functional&gt;, adds &lt;ioswd&gt; </li>
<li>&lt;numeric&gt; no longer includes &lt;iterator&gt;</li>
<li>&lt;string&gt; no longer includes &lt;algorithm&gt; or &lt;memory&gt;</li>
<li>&lt;valarray&gt; no longer includes &lt;numeric&gt; or &lt;cstdlib&gt;</li>
<li>&lt;tr1/hashtable&gt; no longer includes &lt;memory&gt; or &lt;functional&gt;</li>
<li>&lt;tr1/memory&gt; no longer includes &lt;algorithm&gt;</li>
<li>&lt;tr1/random&gt; no longer includes &lt;algorithm&gt; or &lt;fstream&gt;</li>
</ul>
<hr /> <p>
<h3 class="left"> Debug mode for &lt;unordered_map&gt; and &lt;unordered_set&gt;.
<a name="C++ API v1">Fourth, and future</a> </p>
</h3>
<hr /> <p>
<h3 class="left"> Parallel mode first appears.
<a name="Deprecation">Deprecation and Backwards Compatibility</a> </p>
</h3>
<hr /> <p>Variadic template implementations of items in &lt;tuple&gt; and
<h3 class="left"> &lt;functional&gt;.
<a name="Links">Links</a> </p>
</h3>
<p> <p>Default <code>what</code> implementations give more elaborate
<a href="http://www.kegel.com/gcc/gcc4.html">Migrating to gcc-4.1</a>, by Dan Kegel. exception strings for <code>bad_cast</code>,
<code>bad_typeid</code>, <code>bad_exception</code>, and
<code>bad_alloc</code>.
</p> </p>
<p> <p>
<a href="http://lists.debian.org/debian-gcc/2006/03/msg00405.html">Building the whole Debian archive with GCC 4.1: a summary</a>, by Martin Michlmayr PCH binary files no longer installed. Instead, the source files are installed.
</p> </p>
<p> <p>
<a href="http://annwm.lbl.gov/~leggett/Atlas/gcc-3.2.html">Migration guide for GCC-3.2</a> Namespace pb_ds moved to __gnu_pb_ds.
</p> </p>
</body> </body>
......
libstdc++-v3/docs/html/17_intro/backwards_compatibility.html 0 → 100644
<?xml version="1.0" encoding="ISO-8859-1"?>
<!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" xml:lang="en" lang="en">
<head>
<meta name="AUTHOR" content="bkoz@gcc.gnu.org (Benjamin Kosnik), Felix Natter" />
<meta name="KEYWORDS" content="C++, libstdc++, API, backward, compatibility" />
<meta name="DESCRIPTION" content="Backwards Compatibility" />
<meta name="GENERATOR" content="emacs and ten fingers" />
<title>Backwards Compatibility</title>
<link rel="StyleSheet" href="lib3styles.css" type="text/css" />
<link rel="Start" href="documentation.html" type="text/html"
title="GNU C++ Standard Library" />
<link rel="Copyright" href="17_intro/license.html" type="text/html" />
</head>
<body>
<h1 class="centered"><a name="top">Backwards Compatibility</a></h1>
<p class="fineprint"><em>
The latest version of this document is always available at
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/backwards_compatibility.html">
http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/backwards_compatibility.html</a>.
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
<!-- ####################################################### -->
<hr />
<h3 class="left">
<a name="v1">First.</a>
</h3>
<p> The first generation GNU C++ library was called libg++. It was a
separate GNU project, although reliably paired with GCC. Rumors imply
that it had a working relationship with at least two kinds of
dinosaur.
</p>
<p>Known Issues include many of the limitations of its immediate ancestor.</p>
<p>Portability notes and known implementation limitations are as follows.</p>
<h5>No <code>ios_base</code></h5>
<p> At least some older implementations don't have <code>std::ios_base</code>, so you should use <code>std::ios::badbit</code>, <code>std::ios::failbit</code> and <code>std::ios::eofbit</code> and <code>std::ios::goodbit</code>.
</p>
<h5>No <code>cout</code> in <code>ostream.h</code>, no <code>cin</code> in <code>istream.h</code></h5>
<p>
In earlier versions of the standard,
<tt>&lt;fstream.h&gt;</tt>,
<tt>&lt;ostream.h&gt;</tt>
and <tt>&lt;istream.h&gt;</tt>
used to define
<code>cout</code>, <code>cin</code> and so on. ISO C++ specifies that one needs to include
<tt>&lt;iostream&gt;</tt>
explicitly to get the required definitions.
</p>
<p> Some include adjustment may be required.</p>
<p>This project is no longer maintained or supported, and the sources
archived. The code is considered replaced and rewritten.
</p>
<hr />
<h3 class="left">
<a name="v2">Second.</a>
</h3>
<p> The second generation GNU C++ library was called libstdc++, or
libstdc++-v2. It spans the time between libg++ and pre-ISO C++
standardization and is usually associated with the following GCC
releases: egcs 1.x, gcc 2.95, and gcc 2.96.
</p>
<p> The STL portions of this library are based on SGI/HP STL release 3.11.
</p>
<p>Portability notes and known implementation limitations are as follows.</p>
<h5>Namespace <code>std::</code> not supported</h5>
<p>
Some care is required to support C++ compiler and or library
implementation that do not have the standard library in
<code>namespace std</code>.
</p>
<p>
The following sections list some possible solutions to support compilers
that cannot ignore <code>std::</code>-qualified names.
</p>
<p> First, see if the compiler has a flag for this. Namespace
back-portability-issues are generally not a problem for g++
compilers that do not have libstdc++ in <code>std::</code>, as
the compilers use <code>-fno-honor-std</code> (ignore
<code>std::</code>, <code>:: = std::</code>) by default. That
is, the responsibility for enabling or disabling
<code>std::</code> is on the user; the maintainer does not have
to care about it. This probably applies to some other compilers
as well.
</p>
<p>Second, experiment with a variety of pre-processor tricks.</p>
<p> By defining <code>std</code> as a macro, fully-qualified namespace calls become global. Volia. </p>
<pre>
#ifdef WICKEDLY_OLD_COMPILER
# define std
#endif
</pre>
(thanks to Juergen Heinzl who posted this solution on gnu.gcc.help)
<p>Another pre-processor based approach is to define a
macro <code>NAMESPACE_STD</code>, which is defined to either
&quot;&quot; or &quot;std&quot; based on a compile-type test. On GNU
systems, this can be done with autotools by means of an autoconf test
(see below) for <code>HAVE_NAMESPACE_STD</code>, then using that to
set a value for the <code>NAMESPACE_STD</code> macro. At that point,
one is able to use <code>NAMESPACE_STD::string</code>, which will
evaluate to <code>std::string</code> or
<code>::string</code> (ie, in the global namespace on systems that do
not put <code>string</code> in <code>std::</code>). </p>
<pre style="background: #c0c0c0">
dnl @synopsis AC_CXX_NAMESPACE_STD
dnl
dnl If the compiler supports namespace std, define
dnl HAVE_NAMESPACE_STD.
dnl
dnl @category Cxx
dnl @author Todd Veldhuizen
dnl @author Luc Maisonobe <luc@spaceroots.org>
dnl @version 2004-02-04
dnl @license AllPermissive
AC_DEFUN([AC_CXX_NAMESPACE_STD], [
AC_CACHE_CHECK(if g++ supports namespace std,
ac_cv_cxx_have_std_namespace,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([#include <iostream>
std::istream& is = std::cin;],,
ac_cv_cxx_have_std_namespace=yes, ac_cv_cxx_have_std_namespace=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_have_std_namespace" = yes; then
AC_DEFINE(HAVE_NAMESPACE_STD,,[Define if g++ supports namespace std. ])
fi
])
</pre>
<h5>Illegal iterator usage</h5>
<p>
The following illustrate implementation-allowed illegal iterator
use, and then correct use.
</p>
<ul> <li><p>you cannot do
<code>ostream::operator&lt;&lt;(iterator)</code> to print the
address of the iterator =&gt; use <code>operator&lt;&lt;
&amp;*iterator</code> instead
</p></li>
<li><p>you cannot clear an iterator's reference
(<code>iterator = 0</code>) =&gt; use
<code>iterator = iterator_type();</code>
</p></li>
<li><p>
<code>if (iterator)</code> won't work any
more =&gt; use <code>if (iterator != iterator_type())</code>
</p></li>
</ul>
<h5><code>isspace</code> from <tt>&lt;cctype&gt;</tt> is a macro
</h5>
<p> Glibc 2.0.x and 2.1.x define <tt>&lt;ctype.h&gt;</tt>
functionality as macros (isspace, isalpha etc.).
</p>
<p>
This implementations of libstdc++, however, keep these functions as
macros, and so it is not back-portable to use fully qualified
names. For example:
</p>
<pre>
#include &lt;cctype&gt;
int main() { std::isspace('X'); }
</pre>
<p>Results in something like this:
</p>
<pre>
std:: (__ctype_b[(int) ( ( 'X' ) )] &amp; (unsigned short int) _ISspace ) ;
</pre>
<p> A solution is to modify a header-file so that the compiler tells
<tt>&lt;ctype.h&gt;</tt> to define functions instead of macros:
</p>
<pre>
// This keeps isalnum, et al from being propagated as macros.
#if __linux__
# define __NO_CTYPE 1
#endif
</pre>
<p>Then, include &lt;ctype.h&gt;
</p>
<p>
Another problem arises if you put a <code>using namespace std;</code>
declaration at the top, and include <tt>&lt;ctype.h&gt;</tt>. This
will result in ambiguities between the definitions in the global
namespace (<tt>&lt;ctype.h&gt;</tt>) and the definitions in namespace
<code>std::</code> (<code>&lt;cctype&gt;</code>).
</p>
<h5>No <code>vector::at</code>, <code>deque::at</code>, <code>string::at</code></h5>
<p>
One solution is to add an autoconf-test for this:
</p>
<pre style="background: #c0c0c0">
AC_MSG_CHECKING(for container::at)
AC_TRY_COMPILE(
[
#include &lt;vector&gt;
#include &lt;deque&gt;
#include &lt;string&gt;
using namespace std;
],
[
deque&lt;int&gt; test_deque(3);
test_deque.at(2);
vector&lt;int&gt; test_vector(2);
test_vector.at(1);
string test_string(&quot;test_string&quot;);
test_string.at(3);
],
[AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_CONTAINER_AT)],
[AC_MSG_RESULT(no)])
</pre>
<p>
If you are using other (non-GNU) compilers it might be a good idea
to check for <code>string::at</code> separately.
</p>
<h5>No <code>std::char_traits&lt;char&gt;::eof</code></h5>
<p>
Use some kind of autoconf test, plus this:
</p>
<pre>
#ifdef HAVE_CHAR_TRAITS
#define CPP_EOF std::char_traits&lt;char&gt;::eof()
#else
#define CPP_EOF EOF
#endif
</pre>
<h5>No <code>string::clear</code></h5>
<p>
There are two functions for deleting the contents of a string:
<code>clear</code> and <code>erase</code> (the latter
returns the string).
</p>
<pre>
void
clear() { _M_mutate(0, this-&gt;size(), 0); }
</pre>
<pre>
basic_string&amp;
erase(size_type __pos = 0, size_type __n = npos)
{
return this-&gt;replace(_M_check(__pos), _M_fold(__pos, __n),
_M_data(), _M_data());
}
</pre>
<p>
Unfortunately, ut <code>clear</code> is not
implemented in this version, so you should use
<code>erase</code> (which is probably faster than
<code>operator=(charT*)</code>).
</p>
<h5>Removal of <code>ostream::form</code> and
<code>istream::scan</code> extensions</h5>
<p> These are no longer supported. Please use
<a href="#sec-stringstream" title="Using stringstreams">
stringstreams</a> instead.
</p>
<h5>No <code>basic_stringbuf</code>, <code>basic_stringstream</code></h5>
<p>
Although the ISO standard
<code>i/ostringstream</code>-classes are provided, (<tt>&lt;sstream&gt;</tt>), for compatibility with older implementations the pre-ISO <code>i/ostrstream</code> (<tt>&lt;strstream&gt;</tt>) interface is also provided, with these caveats:
</p>
<div class="itemizedlist"><ul type="disc">
<li><p> <code>strstream</code> is considered to be
deprecated
</p></li>
<li><p> <code>strstream</code> is limited to
<code>char</code>
</p></li>
<li><p> with <code>ostringstream</code> you don't
have to take care of terminating the string or freeing its
memory
</p></li>
<li><p> <code>istringstream</code> can be re-filled
(clear(); str(input);)
</p></li>
</ul></div>
<p>
You can then use output-stringstreams like this:
</p>
<pre>
#ifdef HAVE_SSTREAM
# include &lt;sstream&gt;
#else
# include &lt;strstream&gt;
#endif
#ifdef HAVE_SSTREAM
std::ostringstream oss;
#else
std::ostrstream oss;
#endif
oss &lt;&lt; &quot;Name=&quot; &lt;&lt; m_name &lt;&lt; &quot;, number=&quot; &lt;&lt; m_number &lt;&lt; std::endl;
...
#ifndef HAVE_SSTREAM
oss &lt;&lt; std::ends; // terminate the char*-string
#endif
// str() returns char* for ostrstream and a string for ostringstream
// this also causes ostrstream to think that the buffer's memory
// is yours
m_label.set_text(oss.str());
#ifndef HAVE_SSTREAM
// let the ostrstream take care of freeing the memory
oss.freeze(false);
#endif
</pre>
<p>
Input-stringstreams can be used similarly:
</p>
<pre>
std::string input;
...
#ifdef HAVE_SSTREAM
std::istringstream iss(input);
#else
std::istrstream iss(input.c_str());
#endif
int i;
iss &gt;&gt; i;
</pre>
<p> One (the only?) restriction is that an istrstream cannot be re-filled:
</p>
<pre>
std::istringstream iss(numerator);
iss &gt;&gt; m_num;
// this is not possible with istrstream
iss.clear();
iss.str(denominator);
iss &gt;&gt; m_den;
</pre>
<p>
If you don't care about speed, you can put these conversions in
a template-function:
</p>
<pre>
template &lt;class X&gt;
void fromString(const string&amp; input, X&amp; any)
{
#ifdef HAVE_SSTREAM
std::istringstream iss(input);
#else
std::istrstream iss(input.c_str());
#endif
X temp;
iss &gt;&gt; temp;
if (iss.fail())
throw runtime_error(..)
any = temp;
}
</pre>
<p> Another example of using stringstreams is in <a href="../21_strings/howto.html" target="_top">this howto</a>.
</p>
<p> There is additional information in the libstdc++-v2 info files, in
particular &quot;info iostream&quot;.
</p>
<h5>Little or no wide character support</h5>
<h5>No templatized iostreams</h5>
<h5>Thread safety issues</h5>
<p>This project is no longer maintained or supported, and the sources
archived. The code is considered replaced and rewritten.
</p>
<hr />
<h3 class="left">
<a name="v3">Third.</a>
</h3>
<p> The third generation GNU C++ library is called libstdc++, or
libstdc++-v3.
</p>
<p>The subset commonly known as the Standard Template Library
(chapters 23 through 25, mostly) is adapted from the final release
of the SGI STL (version 3.3), with extensive changes.
</p>
<p>A more formal description of the V3 goals can be found in the
official <a href="../17_intro/DESIGN">design document</a>.
</p>
<p>Portability notes and known implementation limitations are as follows.</p>
<h5>Pre-ISO headers moved to backwards or removed</h5>
<p> The pre-ISO C++ headers
(<code>iostream.h</code>, <code>defalloc.h</code> etc.) are
available, unlike previous libstdc++ versions, but inclusion
generates a warning that you are using deprecated headers.
</p>
<p>This compatibility layer is constructed by including the
standard C++ headers, and injecting any items in
<code>std::</code> into the global namespace.
</p>
<p>For those of you new to ISO C++ (welcome, time travelers!), no,
that isn't a typo. Yes, the headers really have new names.
Marshall Cline's C++ FAQ Lite has a good explanation in <a
href="http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.4">item
[27.4]</a>.
</p>
<p> Some include adjustment may be required. What follows is an
autoconf test that defines <code>PRE_STDCXX_HEADERS</code> when they
exist.</p>
<pre style="background: #c0c0c0">
# AC_HEADER_PRE_STDCXX
AC_DEFUN([AC_HEADER_PRE_STDCXX], [
AC_CACHE_CHECK(for pre-ISO C++ include files,
ac_cv_cxx_pre_stdcxx,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -Wno-deprecated"
# Omit defalloc.h, as compilation with newer compilers is problematic.
AC_TRY_COMPILE([
#include &lt;new.h&gt;
#include &lt;iterator.h&gt;
#include &lt;alloc.h&gt;
#include &lt;set.h&gt;
#include &lt;hashtable.h&gt;
#include &lt;hash_set.h&gt;
#include &lt;fstream.h&gt;
#include &lt;tempbuf.h&gt;
#include &lt;istream.h&gt;
#include &lt;bvector.h&gt;
#include &lt;stack.h&gt;
#include &lt;rope.h&gt;
#include &lt;complex.h&gt;
#include &lt;ostream.h&gt;
#include &lt;heap.h&gt;
#include &lt;iostream.h&gt;
#include &lt;function.h&gt;
#include &lt;multimap.h&gt;
#include &lt;pair.h&gt;
#include &lt;stream.h&gt;
#include &lt;iomanip.h&gt;
#include &lt;slist.h&gt;
#include &lt;tree.h&gt;
#include &lt;vector.h&gt;
#include &lt;deque.h&gt;
#include &lt;multiset.h&gt;
#include &lt;list.h&gt;
#include &lt;map.h&gt;
#include &lt;algobase.h&gt;
#include &lt;hash_map.h&gt;
#include &lt;algo.h&gt;
#include &lt;queue.h&gt;
#include &lt;streambuf.h&gt;
],,
ac_cv_cxx_pre_stdcxx=yes, ac_cv_cxx_pre_stdcxx=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_pre_stdcxx" = yes; then
AC_DEFINE(PRE_STDCXX_HEADERS,,[Define if pre-ISO C++ header files are present. ])
fi
])
</pre>
<p>Porting between pre-ISO headers and ISO headers is simple: headers
like &lt;vector.h&gt; can be replaced with &lt;vector&gt; and a using
directive <code>using namespace std;</code> can be put at the global
scope. This should be enough to get this code compiling, assuming the
other usage is correct.
</p>
<h5>Extension headers hash_map, hash_set moved to ext or backwards</h5>
<p> Header files <code>hash_map</code> and <code>hash_set</code> moved
to <code>ext/hash_map</code> and <code>ext/hash_set</code>,
respectively. At the same time, all types in these files are enclosed
in <code>namespace __gnu_cxx</code>. Later versions move deprecate
these files, and suggest using TR1's <code>unordered_map</code>
and <code>unordered_set</code> instead.
</p>
<p>The following autoconf tests check for working HP/SGI hash containers.
</p>
<pre style="background: #c0c0c0">
# AC_HEADER_EXT_HASH_MAP
AC_DEFUN([AC_HEADER_EXT_HASH_MAP], [
AC_CACHE_CHECK(for ext/hash_map,
ac_cv_cxx_ext_hash_map,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -Werror"
AC_TRY_COMPILE([#include <ext/hash_map>], [using __gnu_cxx::hash_map;],
ac_cv_cxx_ext_hash_map=yes, ac_cv_cxx_ext_hash_map=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_ext_hash_map" = yes; then
AC_DEFINE(HAVE_EXT_HASH_MAP,,[Define if ext/hash_map is present. ])
fi
])
</pre>
<pre style="background: #c0c0c0">
# AC_HEADER_EXT_HASH_SET
AC_DEFUN([AC_HEADER_EXT_HASH_SET], [
AC_CACHE_CHECK(for ext/hash_set,
ac_cv_cxx_ext_hash_set,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -Werror"
AC_TRY_COMPILE([#include <ext/hash_set>], [using __gnu_cxx::hash_set;],
ac_cv_cxx_ext_hash_set=yes, ac_cv_cxx_ext_hash_set=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_ext_hash_set" = yes; then
AC_DEFINE(HAVE_EXT_HASH_SET,,[Define if ext/hash_set is present. ])
fi
])
</pre>
<h5>
No <code>ios::nocreate/ios::noreplace</code>.
</h5>
<p> The existence of <code>ios::nocreate</code> being used for
input-streams has been confirmed, most probably because the author
thought it would be more correct to specify nocreate explicitly. So
it can be left out for input-streams.
</p>
<p>For output streams, &quot;nocreate&quot; is probably the default,
unless you specify <code>std::ios::trunc</code> ? To be safe, you can
open the file for reading, check if it has been opened, and then
decide whether you want to create/replace or not. To my knowledge,
even older implementations support <code>app</code>, <code>ate</code>
and <code>trunc</code> (except for <code>app</code> ?).
</p>
<h5>
No <code>stream::attach(int fd)</code>
</h5>
<p>
Phil Edwards writes: It was considered and rejected for the ISO
standard. Not all environments use file descriptors. Of those
that do, not all of them use integers to represent them.
</p>
<p>
For a portable solution (among systems which use
filedescriptors), you need to implement a subclass of
<code>std::streambuf</code> (or
<code>std::basic_streambuf&lt;..&gt;</code>) which opens a file
given a descriptor, and then pass an instance of this to the
stream-constructor.
</p>
<p>
An extension is available that implements this.
<code>&lt;ext/stdio_filebuf.h&gt;</code> contains a derived class called
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/class____gnu__cxx_1_1stdio__filebuf.html"><code>__gnu_cxx::stdio_filebuf</code></a>.
This class can be constructed from a C <code>FILE*</code> or a file
descriptor, and provides the <code>fd()</code> function.
</p>
<p>
For another example of this, refer to
<a href="http://www.josuttis.com/cppcode/fdstream.html" target="_top">fdstream example</a>
by Nicolai Josuttis.
</p>
<h5>
Support for C++98 dialect.
</h5>
<p>Check for complete library coverage of the C++1998/2003 standard.
</p>
<pre style="background: #c0c0c0">
# AC_HEADER_STDCXX_98
AC_DEFUN([AC_HEADER_STDCXX_98], [
AC_CACHE_CHECK(for ISO C++ 98 include files,
ac_cv_cxx_stdcxx_98,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([
#include &lt;cassert&gt;
#include &lt;cctype&gt;
#include &lt;cerrno&gt;
#include &lt;cfloat&gt;
#include &lt;ciso646&gt;
#include &lt;climits&gt;
#include &lt;clocale&gt;
#include &lt;cmath&gt;
#include &lt;csetjmp&gt;
#include &lt;csignal&gt;
#include &lt;cstdarg&gt;
#include &lt;cstddef&gt;
#include &lt;cstdio&gt;
#include &lt;cstdlib&gt;
#include &lt;cstring&gt;
#include &lt;ctime&gt;
#include &lt;algorithm&gt;
#include &lt;bitset&gt;
#include &lt;complex&gt;
#include &lt;deque&gt;
#include &lt;exception&gt;
#include &lt;fstream&gt;
#include &lt;functional&gt;
#include &lt;iomanip&gt;
#include &lt;ios&gt;
#include &lt;iosfwd&gt;
#include &lt;iostream&gt;
#include &lt;istream&gt;
#include &lt;iterator&gt;
#include &lt;limits&gt;
#include &lt;list&gt;
#include &lt;locale&gt;
#include &lt;map&gt;
#include &lt;memory&gt;
#include &lt;new&gt;
#include &lt;numeric&gt;
#include &lt;ostream&gt;
#include &lt;queue&gt;
#include &lt;set&gt;
#include &lt;sstream&gt;
#include &lt;stack&gt;
#include &lt;stdexcept&gt;
#include &lt;streambuf&gt;
#include &lt;string&gt;
#include &lt;typeinfo&gt;
#include &lt;utility&gt;
#include &lt;valarray&gt;
#include &lt;vector&gt;
],,
ac_cv_cxx_stdcxx_98=yes, ac_cv_cxx_stdcxx_98=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_stdcxx_98" = yes; then
AC_DEFINE(STDCXX_98_HEADERS,,[Define if ISO C++ 1998 header files are present. ])
fi
])
</pre>
<h5>
Support for C++TR1 dialect.
</h5>
<p>Check for library coverage of the TR1 standard.
</p>
<pre style="background: #c0c0c0">
# AC_HEADER_STDCXX_TR1
AC_DEFUN([AC_HEADER_STDCXX_TR1], [
AC_CACHE_CHECK(for ISO C++ TR1 include files,
ac_cv_cxx_stdcxx_tr1,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([
#include &lt;tr1/array&gt;
#include &lt;tr1/ccomplex&gt;
#include &lt;tr1/cctype&gt;
#include &lt;tr1/cfenv&gt;
#include &lt;tr1/cfloat&gt;
#include &lt;tr1/cinttypes&gt;
#include &lt;tr1/climits&gt;
#include &lt;tr1/cmath&gt;
#include &lt;tr1/complex&gt;
#include &lt;tr1/cstdarg&gt;
#include &lt;tr1/cstdbool&gt;
#include &lt;tr1/cstdint&gt;
#include &lt;tr1/cstdio&gt;
#include &lt;tr1/cstdlib&gt;
#include &lt;tr1/ctgmath&gt;
#include &lt;tr1/ctime&gt;
#include &lt;tr1/cwchar&gt;
#include &lt;tr1/cwctype&gt;
#include &lt;tr1/functional&gt;
#include &lt;tr1/memory&gt;
#include &lt;tr1/random&gt;
#include &lt;tr1/regex&gt;
#include &lt;tr1/tuple&gt;
#include &lt;tr1/type_traits&gt;
#include &lt;tr1/unordered_set&gt;
#include &lt;tr1/unordered_map&gt;
#include &lt;tr1/utility&gt;
],,
ac_cv_cxx_stdcxx_tr1=yes, ac_cv_cxx_stdcxx_tr1=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_stdcxx_tr1" = yes; then
AC_DEFINE(STDCXX_TR1_HEADERS,,[Define if ISO C++ TR1 header files are present. ])
fi
])
</pre>
<p>An alternative is to check just for specific TR1 includes, such as &lt;unordered_map&gt; and &lt;unordered_set&gt;.
</p>
<pre style="background: #c0c0c0">
# AC_HEADER_TR1_UNORDERED_MAP
AC_DEFUN([AC_HEADER_TR1_UNORDERED_MAP], [
AC_CACHE_CHECK(for tr1/unordered_map,
ac_cv_cxx_tr1_unordered_map,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([#include &lt;tr1/unordered_map&gt;], [using std::tr1::unordered_map;],
ac_cv_cxx_tr1_unordered_map=yes, ac_cv_cxx_tr1_unordered_map=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_tr1_unordered_map" = yes; then
AC_DEFINE(HAVE_TR1_UNORDERED_MAP,,[Define if tr1/unordered_map is present. ])
fi
])
</pre>
<pre style="background: #c0c0c0">
# AC_HEADER_TR1_UNORDERED_SET
AC_DEFUN([AC_HEADER_TR1_UNORDERED_SET], [
AC_CACHE_CHECK(for tr1/unordered_set,
ac_cv_cxx_tr1_unordered_set,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([#include &lt;tr1/unordered_set&gt;], [using std::tr1::unordered_set;],
ac_cv_cxx_tr1_unordered_set=yes, ac_cv_cxx_tr1_unordered_set=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_tr1_unordered_set" = yes; then
AC_DEFINE(HAVE_TR1_UNORDERED_SET,,[Define if tr1/unordered_set is present. ])
fi
])
</pre>
<h5>
Support for C++0x dialect.
</h5>
<p>Check for baseline language coverage in the compiler for the C++0xstandard.
</p>
<pre style="background: #c0c0c0">
# AC_COMPILE_STDCXX_OX
AC_DEFUN([AC_COMPILE_STDCXX_0X], [
AC_CACHE_CHECK(if g++ supports C++0x features without additional flags,
ac_cv_cxx_compile_cxx0x_native,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([
template &lt;typename T&gt;
struct check
{
static_assert(sizeof(int) &lt;= sizeof(T), "not big enough");
};
typedef check&lt;check&lt;bool&gt;&gt; right_angle_brackets;
int a;
decltype(a) b;
typedef check&lt;int&gt; check_type;
check_type c;
check_type&& cr = c;],,
ac_cv_cxx_compile_cxx0x_native=yes, ac_cv_cxx_compile_cxx0x_native=no)
AC_LANG_RESTORE
])
AC_CACHE_CHECK(if g++ supports C++0x features with -std=c++0x,
ac_cv_cxx_compile_cxx0x_cxx,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -std=c++0x"
AC_TRY_COMPILE([
template &lt;typename T&gt;
struct check
{
static_assert(sizeof(int) &lt;= sizeof(T), "not big enough");
};
typedef check&lt;check&lt;bool&gt;&gt; right_angle_brackets;
int a;
decltype(a) b;
typedef check&lt;int&gt; check_type;
check_type c;
check_type&& cr = c;],,
ac_cv_cxx_compile_cxx0x_cxx=yes, ac_cv_cxx_compile_cxx0x_cxx=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
AC_CACHE_CHECK(if g++ supports C++0x features with -std=gnu++0x,
ac_cv_cxx_compile_cxx0x_gxx,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([
template &lt;typename T&gt;
struct check
{
static_assert(sizeof(int) &lt;= sizeof(T), "not big enough");
};
typedef check&lt;check&lt;bool&gt;&gt; right_angle_brackets;
int a;
decltype(a) b;
typedef check&lt;int&gt; check_type;
check_type c;
check_type&& cr = c;],,
ac_cv_cxx_compile_cxx0x_gxx=yes, ac_cv_cxx_compile_cxx0x_gxx=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_compile_cxx0x_native" = yes ||
test "$ac_cv_cxx_compile_cxx0x_cxx" = yes ||
test "$ac_cv_cxx_compile_cxx0x_gxx" = yes; then
AC_DEFINE(HAVE_STDCXX_0X,,[Define if g++ supports C++0x features. ])
fi
])
</pre>
<p>Check for library coverage of the C++0xstandard.
</p>
<pre style="background: #c0c0c0">
# AC_HEADER_STDCXX_0X
AC_DEFUN([AC_HEADER_STDCXX_0X], [
AC_CACHE_CHECK(for ISO C++ 0x include files,
ac_cv_cxx_stdcxx_0x,
[AC_REQUIRE([AC_COMPILE_STDCXX_0X])
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([
#include &lt;cassert&gt;
#include &lt;ccomplex&gt;
#include &lt;cctype&gt;
#include &lt;cerrno&gt;
#include &lt;cfenv&gt;
#include &lt;cfloat&gt;
#include &lt;cinttypes&gt;
#include &lt;ciso646&gt;
#include &lt;climits&gt;
#include &lt;clocale&gt;
#include &lt;cmath&gt;
#include &lt;csetjmp&gt;
#include &lt;csignal&gt;
#include &lt;cstdarg&gt;
#include &lt;cstdbool&gt;
#include &lt;cstddef&gt;
#include &lt;cstdint&gt;
#include &lt;cstdio&gt;
#include &lt;cstdlib&gt;
#include &lt;cstring&gt;
#include &lt;ctgmath&gt;
#include &lt;ctime&gt;
#include &lt;cwchar&gt;
#include &lt;cwctype&gt;
#include &lt;algorithm&gt;
#include &lt;array&gt;
#include &lt;bitset&gt;
#include &lt;complex&gt;
#include &lt;deque&gt;
#include &lt;exception&gt;
#include &lt;fstream&gt;
#include &lt;functional&gt;
#include &lt;iomanip&gt;
#include &lt;ios&gt;
#include &lt;iosfwd&gt;
#include &lt;iostream&gt;
#include &lt;istream&gt;
#include &lt;iterator&gt;
#include &lt;limits&gt;
#include &lt;list&gt;
#include &lt;locale&gt;
#include &lt;map&gt;
#include &lt;memory&gt;
#include &lt;new&gt;
#include &lt;numeric&gt;
#include &lt;ostream&gt;
#include &lt;queue&gt;
#include &lt;random&gt;
#include &lt;regex&gt;
#include &lt;set&gt;
#include &lt;sstream&gt;
#include &lt;stack&gt;
#include &lt;stdexcept&gt;
#include &lt;streambuf&gt;
#include &lt;string&gt;
#include &lt;tuple&gt;
#include &lt;typeinfo&gt;
#include &lt;type_traits&gt;
#include &lt;unordered_map&gt;
#include &lt;unordered_set&gt;
#include &lt;utility&gt;
#include &lt;valarray&gt;
#include &lt;vector&gt;
],,
ac_cv_cxx_stdcxx_0x=yes, ac_cv_cxx_stdcxx_0x=no)
AC_LANG_RESTORE
CXXFLAGS="$ac_save_CXXFLAGS"
])
if test "$ac_cv_cxx_stdcxx_0x" = yes; then
AC_DEFINE(STDCXX_0X_HEADERS,,[Define if ISO C++ 0x header files are present. ])
fi
])
</pre>
<p>As is the case for TR1 support, these autoconf macros can be made for a finer-grained, per-header-file check. For &lt;unordered_map&gt;
</p>
<pre style="background: #c0c0c0">
# AC_HEADER_UNORDERED_MAP
AC_DEFUN([AC_HEADER_UNORDERED_MAP], [
AC_CACHE_CHECK(for unordered_map,
ac_cv_cxx_unordered_map,
[AC_REQUIRE([AC_COMPILE_STDCXX_0X])
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([#include &lt;unordered_map&gt;], [using std::unordered_map;],
ac_cv_cxx_unordered_map=yes, ac_cv_cxx_unordered_map=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_unordered_map" = yes; then
AC_DEFINE(HAVE_UNORDERED_MAP,,[Define if unordered_map is present. ])
fi
])
</pre>
<pre style="background: #c0c0c0">
# AC_HEADER_UNORDERED_SET
AC_DEFUN([AC_HEADER_UNORDERED_SET], [
AC_CACHE_CHECK(for unordered_set,
ac_cv_cxx_unordered_set,
[AC_REQUIRE([AC_COMPILE_STDCXX_0X])
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([#include &lt;unordered_set&gt;], [using std::unordered_set;],
ac_cv_cxx_unordered_set=yes, ac_cv_cxx_unordered_set=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_unordered_set" = yes; then
AC_DEFINE(HAVE_UNORDERED_SET,,[Define if unordered_set is present. ])
fi
])
</pre>
<h5>
Container iterator_type is not necessarily container value_type*
</h5>
<hr />
<h3 class="left">
<a name="v4">Fourth, and future</a>
</h3>
<hr />
<h3 class="left">
<a name="Links">Links</a>
</h3>
<p>
<a href="http://www.kegel.com/gcc/gcc4.html">Migrating to gcc-4.1</a>, by Dan Kegel.
</p>
<p>
<a href="http://lists.debian.org/debian-gcc/2006/03/msg00405.html">Building the whole Debian archive with GCC 4.1: a summary</a>, by Martin Michlmayr
</p>
<p>
<a href="http://annwm.lbl.gov/~leggett/Atlas/gcc-3.2.html">Migration guide for GCC-3.2</a>
</p>
</body>
</html>
libstdc++-v3/docs/html/17_intro/howto.html
...@@ -34,123 +34,309 @@ ...@@ -34,123 +34,309 @@
<hr /> <hr />
<h1>Contents</h1> <h1>Contents</h1>
<ul> <ul>
<li><a href="#2.1">Header Files</a></li> <li><a href="#2.0">Header Files</a></li>
<li><a href="#5">Implementation specific behavior</a></li> <li><a href="#3.0">Namespaces</a></li>
<li><a href="#6">Macros</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> </ul>
<hr /> <hr />
<!-- ####################################################### --> <!-- ####################################################### -->
<h2><a name="2.1">Header Files</a></h2> <h2><a name="2.0">Header Files</a></h2>
<p>The C++ standard specifies 50 header files that must be <p>The C++ standard specifies the entire set of header files that must be
available to all hosted implementations. Actually, the word available to all hosted implementations. Actually, the word
&quot;files&quot; is a misnomer, since the contents of the headers &quot;files&quot; is a misnomer, since the contents of the headers
don't necessarily have to be in any kind of external file. The 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 only rule is that when one <code>#include</code>'s a header, the
contents of that header, as defined by the Standard, become contents of that header become
available, no matter how. available, no matter how.
</p> </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> </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>&lt;algorithm&gt;</td><td>&lt;iomanip&gt;</td><td>&lt;list&gt;</td><td>&lt;ostream&gt;</td><td>&lt;streambuf&gt;</td></tr>
<tr><td>&lt;bitset&gt;</td><td>&lt;ios&gt;</td><td>&lt;locale&gt;</td><td>&lt;queue&gt;</td><td>&lt;string&gt;</td></tr>
<tr><td>&lt;complex&gt;</td><td>&lt;iosfwd&gt;</td><td>&lt;map&gt;</td><td>&lt;set&gt;</td><td>&lt;typeinfo&gt;</td></tr>
<tr><td>&lt;deque&gt;</td><td>&lt;iostream&gt;</td><td>&lt;memory&gt;</td><td>&lt;sstream&gt;</td><td>&lt;utility&gt;</td></tr>
<tr><td>&lt;exception&gt;</td><td>&lt;istream&gt;</td><td>&lt;new&gt;</td><td>&lt;stack&gt;</td><td>&lt;valarray&gt;</td></tr>
<tr><td>&lt;fstream&gt;</td><td>&lt;iterator&gt;</td><td>&lt;numeric&gt;</td><td>&lt;stdexcept&gt;</td><td>&lt;vector&gt;</td></tr>
<tr><td>&lt;functional&gt;</td><td>&lt;limits&gt;</td></tr>
</table></center>
<p></p>
<center><table border="1"><caption>C++98 Headers for C Library Facilities</caption>
<tr><td>&lt;cassert&gt;</td><td>&lt;ciso646&gt;</td><td>&lt;csetjmp&gt;</td><td>&lt;cstdio&gt;</td><td>&lt;ctime&gt;</td></tr>
<tr><td>&lt;cctype&gt;</td><td>&lt;climits&gt;</td><td>&lt;csignal&gt;</td><td>&lt;cstdlib&gt;</td><td>&lt;cwchar&gt;</td></tr>
<tr><td>&lt;cerrno&gt;</td><td>&lt;clocale&gt;</td><td>&lt;cstdarg&gt;</td><td>&lt;cstring&gt;</td><td>&lt;cwctype&gt;</td></tr>
<tr><td>&lt;cfloat&gt;</td><td>&lt;cmath&gt;</td><td>&lt;cstddef&gt;</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> </p>
<center><table border="1"><caption>C++0x Library Headers</caption>
<tr><td>&lt;algorithm&gt;</td><td>&lt;iomanip&gt;</td><td>&lt;locale&gt;</td><td>&lt;regex&gt;</td><td>&lt;tuple&gt;</td></tr>
<tr><td>&lt;array&gt;</td><td>&lt;ios&gt;</td><td>&lt;map&gt;</td><td>&lt;set&gt;</td><td>&lt;typeinfo&gt;</td></tr>
<tr><td>&lt;bitset&gt;</td><td>&lt;iosfwd&gt;</td><td>&lt;memory&gt;</td><td>&lt;sstream&gt;</td><td>&lt;type_traits&gt;</td></tr>
<tr><td>&lt;complex&gt;</td><td>&lt;iostream&gt;</td><td>&lt;new&gt;</td><td>&lt;stack&gt;</td><td>&lt;unordered_map&gt;</td></tr>
<tr><td>&lt;deque&gt;</td><td>&lt;istream&gt;</td><td>&lt;numeric&gt;</td><td>&lt;stdexcept&gt;</td><td>&lt;unordered_set&gt;</td></tr>
<tr><td>&lt;exception&gt;</td><td>&lt;iterator&gt;</td><td>&lt;ostream&gt;</td><td>&lt;streambuf&gt;</td><td>&lt;utility&gt;</td></tr>
<tr><td>&lt;fstream&gt;</td><td>&lt;limits&gt;</td><td>&lt;queue&gt;</td><td>&lt;string&gt;</td><td>&lt;valarray&gt;</td></tr>
<tr><td>&lt;functional&gt;</td><td>&lt;list&gt;</td><td>&lt;random&gt;</td><td>&lt;system_error&gt;</td><td>&lt;vector&gt;</td></tr>
</table></center>
<p></p>
<center><table border="1"><caption>C++0x Headers for C Library Facilities</caption>
<tr><td>&lt;cassert&gt;</td><td>&lt;cfloat&gt;</td><td>&lt;cmath&gt;</td><td>&lt;cstddef&gt;</td><td>&lt;ctgmath&gt;</td></tr>
<tr><td>&lt;ccomplex&gt;</td><td>&lt;cinttypes&gt;</td><td>&lt;csetjmp&gt;</td><td>&lt;cstdint&gt;</td><td>&lt;ctime&gt;</td></tr>
<tr><td>&lt;cctype&gt;</td><td>&lt;ciso646&gt;</td><td>&lt;csignal&gt;</td><td>&lt;cstdio&gt;</td><td>&lt;cuchar&gt;</td></tr>
<tr><td>&lt;cerrno&gt;</td><td>&lt;climits&gt;</td><td>&lt;cstdarg&gt;</td><td>&lt;cstdlib&gt;</td><td>&lt;cwchar&gt;</td></tr>
<tr><td>&lt;cfenv&gt;</td><td>&lt;clocale&gt;</td><td>&lt;cstdbool&gt;</td><td>&lt;cstring&gt;</td><td>&lt;cwctype&gt;</td></tr>
</table></center>
<p>In addition, TR1 includes as:
</p>
<center><table border="1"><caption>TR1 Library Headers</caption>
<tr><td>&lt;tr1/array&gt;</td><td>&lt;tr1/memory&gt;</td><td>&lt;tr1/regex&gt;</td><td>&lt;tr1/type_traits&gt;</td><td>&lt;tr1/unordered_set&gt;</td></tr>
<tr><td>&lt;tr1/complex&gt;</td><td>&lt;tr1/random&gt;</td><td>&lt;tr1/tuple&gt;</td><td>&lt;tr1/unordered_map&gt;</td><td>&lt;tr1/utility&gt;</td></tr>
<tr><td>&lt;tr1/functional&gt;</td></tr>
</table></center>
<p></p>
<center><table border="1"><caption>TR1 Headers for C Library Facilities</caption>
<tr><td>&lt;tr1/cmath&gt;</td><td>&lt;tr1/cfloat&gt;</td><td>&lt;tr1/cstdarg&gt;</td><td>&lt;tr1/cstdio&gt;</td><td>&lt;tr1/ctime&gt;</td></tr>
<tr><td>&lt;tr1/ccomplex&gt;</td><td>&lt;tr1/cinttypes&gt;</td><td>&lt;tr1/cstdbool&gt;</td><td>&lt;tr1/cstdlib&gt;</td><td>&lt;tr1/cwchar&gt;</td></tr>
<tr><td>&lt;tr1/cfenv&gt;</td><td>&lt;tr1/climits&gt;</td><td>&lt;tr1/cstdint&gt;</td><td>&lt;tr1/ctgmath&gt;</td><td>&lt;tr1/cwctype&gt;<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>&lt;cxxabi.h&gt;</td><td>&lt;cxxabi_forced.h&gt;</td></tr>
</table></center>
<p>And a large variety of extensions.
</p>
<center><table border="1"><caption>Extension Headers</caption>
<tr><td>&lt;ext/algorithm&gt;</td><td>&lt;ext/debug_allocator.h&gt;</td><td>&lt;ext/mt_allocator.h&gt;</td><td>&lt;ext/pod_char_traits.h&gt;</td><td>&lt;ext/stdio_sync_filebuf.h&gt;</td></tr>
<tr><td>&lt;ext/array_allocator.h&gt;</td><td>&lt;ext/enc_filebuf.h&gt;</td><td>&lt;ext/new_allocator.h&gt;</td><td>&lt;ext/pool_allocator.h&gt;</td><td>&lt;ext/throw_allocator.h&gt;</td></tr>
<tr><td>&lt;ext/atomicity.h&gt;</td><td>&lt;ext/functional&gt;</td><td>&lt;ext/numeric&gt;</td><td>&lt;ext/rb_tree&gt;</td><td>&lt;ext/typelist.h&gt;<td></tr>
<tr><td>&lt;ext/bitmap_allocator.h&gt;</td><td>&lt;ext/iterator&gt;</td><td>&lt;ext/numeric_traits.h&gt;</td><td>&lt;ext/rope&gt;</td><td>&lt;ext/type_traits.h&gt;</td></tr>
<tr><td>&lt;ext/codecvt_specializations.h&gt;</td><td>&lt;ext/malloc_allocator.h&gt;</td><td>&lt;ext/pb_ds/assoc_container.h&gt;</td><td>&lt;ext/slist&gt;</td><td>&lt;ext/vstring.h&gt;</td></tr>
<tr><td>&lt;ext/concurrence.h&gt;</td><td>&lt;ext/memory&gt;</td><td>&lt;ext/pb_ds/priority_queue.h&gt;</td><td>&lt;ext/stdio_filebuf.h&gt;</td></tr>
</table></center>
<p></p>
<center><table border="1"><caption>Extension Debug Headers</caption>
<tr><td>&lt;debug/bitset&gt;</td><td>&lt;debug/list&gt;</td><td>&lt;debug/set&gt;</td><td>&lt;debug/unordered_map&gt;</td><td>&lt;debug/vector&gt;</td></tr>
<tr><td>&lt;debug/deque&gt;</td><td>&lt;debug/map&gt;</td><td>&lt;debug/string&gt;</td><td>&lt;debug/unordered_set&gt;</td></tr>
</table></center>
<p></p>
<center><table border="1"><caption>Extension Parallel Headers</caption>
<tr><td>&lt;parallel/algorithm&gt;</td><td>&lt;parallel/numeric&gt;</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> <pre>
C++ Library Headers #include &lt;array&gt;
algorithm ios new stack #include &lt;functional&gt;
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
</pre> </pre>
<p>In addition, TR1 includes as: <p>Implies C++0x mode. To use the entities in &lt;array&gt;, the C++0x
compilation mode must be used, which implies the C++0x functionality
(and deprecations) in &lt;functional&gt; 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>
<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> <pre>
C++ Library Headers #include &lt;tr1/type_traits&gt;
tr1/array, tr1/complex, tr1/functional, tr1/memory, tr1/random, #include &lt;type_traits&gt;
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
</pre> </pre>
<p> Several parts of C++0x diverge quite substantially from TR1 predecessors.
</p>
<hr /> <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> <p>
You should not use the C-headers (except for system-level The standard specifies that if one includes the C-style header
headers) from C++ programs. Instead, you should use a set of (&lt;math.h&gt; in this case), the symbols will be available
headers that are named by prepending 'c' and, as usual, in the global namespace and perhaps in
omitting the extension (.h). For example, instead of using namespace <code>std::</code> (but this is no longer a firm
<tt>&lt;math.h&gt;</tt>, you requirement.) One the other hand, including the C++-style
should use <tt>&lt;cmath&gt;</tt>. In some cases this has header (&lt;cmath&gt;) guarantees that the entities will be
the advantage that the C++-header is more standardized than found in namespace std and perhaps in the global namespace.
the C-header (i.e. <tt>&lt;ctime&gt;</tt> (almost) </p>
corresponds to either <tt>&lt;time.h&gt;</tt> or <tt>&lt;sys/time.h&gt;</tt>).
The standard specifies that if you include the C-style header
(<tt>&lt;math.h&gt;</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>&lt;cmath&gt;</tt>), the symbols
will only be defined in namespace <code>std::</code>
(and macros will be converted to inline-functions).
</p>
<p>FIXME: this is no longer accurate.</p>
<p> <p>
For more information on this, and for information on how the Usage of C++-style headers is recommended, as then
GNU C++ implementation might reuse (&quot;shadow&quot;) the C C-linkage names can be disambiguated by explicit qualification, such
library-functions, have a look at <a href="http://www.cantrip.org/cheaders.html" target="_top"> as by <code>std::abort</code>. In addition, the C++-style headers can
www.cantrip.org</a>. use function overloading to provide a simpler interface to certain
</p> families of C-functions. For instance in &lt;cmath&gt;, 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 &lt;stdc++.h&gt;, and adds all the TR1 headers.
</p>
</li>
<li>extc++.h
<p>Includes all of &lt;stdtr1c++.h&gt;, 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 /> <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> <p>
One standard requirement is that the library components are defined 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. ...@@ -167,37 +353,46 @@ should not be used in a global context, like header files.
qualified name</i></span> for each library symbol qualified name</i></span> for each library symbol
(i.e. <code>std::string</code>, <code>std::cout</code>) Always can be (i.e. <code>std::string</code>, <code>std::cout</code>) Always can be
used, and usually enhanced, by strategic use of typedefs. (In the 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> </p></li>
</ul></div> </ul></div>
<hr /> <hr />
<h2><a name="2.6">Using namespace composition</a></h2> <h2><a name="3.2">Using namespace composition</a></h2>
<p> <p>
<a href="http://gtkmm.sourceforge.net" target="_top">Gtk--</a> defines Best practice in programming suggests sequestering new data or
most of its classes in namespace Gtk::. Thus, it was possible to functionality in a sanely-named, unique namespace whenever
adapt Gtk-- to namespace std:: by using a C++-feature called 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 <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 namespace-definition: the imported symbol(s) gets imported into the
currently active namespace(s). For example: currently active namespace(s). For example:
</p> </p>
<pre class="programlisting"> <pre class="programlisting">
namespace Gtk { namespace gtk
{
using std::string; using std::string;
class Window { ... } using std::tr1::array;
}
</pre> class Window { ... };
}
</pre>
<p> <p>
In this example, <code>std::string</code> gets imported into In this example, <code>std::string</code> gets imported into
namespace Gtk::. The result is that you don't have to use <code>namespace gtk</code>. The result is that use of
<code>std::string</code> in this header, but still <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 <code>std::string</code> does not get imported into
the global namespace (::) unless the user does the global namespace. Additionally, a more elaborate arrangement can be made for backwards compatibility and portability, whereby the
<code>using namespace Gtk;</code> (which is not recommended <code>using</code>-declarations can wrapped in macros that
practice for Gtk--, so it is not a problem). Additionally, the
<code>using</code>-declarations are wrapped in macros that
are set based on autoconf-tests to either &quot;&quot; or i.e. <code>using are set based on autoconf-tests to either &quot;&quot; or i.e. <code>using
std::string;</code> (depending on whether the system has std::string;</code> (depending on whether the system has
libstdc++ in <code>std::</code> or not). (ideas from libstdc++ in <code>std::</code> or not). (ideas from
...@@ -206,7 +401,103 @@ cases where the qualified verbage becomes unweidly.) ...@@ -206,7 +401,103 @@ cases where the qualified verbage becomes unweidly.)
</p> </p>
<hr /> <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>&quot;Configurable&quot; (or &quot;Not configurable&quot;) 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> &quot;ABI&quot; 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 <p>This section discusses issues surrounding the proper compilation
of multithreaded applications which use the Standard C++ of multithreaded applications which use the Standard C++
library. This information is GCC-specific since the C++ library. This information is GCC-specific since the C++
...@@ -419,107 +710,11 @@ cases where the qualified verbage becomes unweidly.) ...@@ -419,107 +710,11 @@ cases where the qualified verbage becomes unweidly.)
<a href="../faq/index.html">to the FAQ</a>. <a href="../faq/index.html">to the FAQ</a>.
</p> </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>&quot;Configurable&quot; (or &quot;Not configurable&quot;) 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> &quot;ABI&quot; 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> <dt><code></code></dt>
<dd> <dd>
</dd> </dd>
--> -->
</dl>
<p>Return <a href="#top">to top of page</a> or <p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>. <a href="../faq/index.html">to the FAQ</a>.
</p> </p>
......
libstdc++-v3/docs/html/18_support/howto.html
...@@ -281,9 +281,6 @@ ...@@ -281,9 +281,6 @@
</p> </p>
<pre> <pre>
std::set_terminate(std::abort);</pre> std::set_terminate(std::abort);</pre>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<p> <p>
This function will attempt to write to stderr. If your application This function will attempt to write to stderr. If your application
...@@ -292,6 +289,11 @@ ...@@ -292,6 +289,11 @@
unspecified manner. unspecified manner.
</p> </p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<hr /> <hr />
<h2><a name="5">Dynamic memory management</a></h2> <h2><a name="5">Dynamic memory management</a></h2>
<p>There are six flavors each of <code>new</code> and <p>There are six flavors each of <code>new</code> and
......
libstdc++-v3/docs/html/20_util/allocator.html
...@@ -84,32 +84,45 @@ ...@@ -84,32 +84,45 @@
</h3> </h3>
<p>The easiest way of fulfilling the requirements is to call operator new <p>The easiest way of fulfilling the requirements is to call operator new
each time a container needs memory, and to call operator delete each each time a container needs memory, and to call operator delete each
time the container releases memory. <strong>BUT</strong> time the container releases memory. This method may be
<a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00105.html">this <a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00105.html">slower</a>
method is horribly slow</a>. than caching the allocations and re-using previously-allocated
</p> memory, but has the advantage of working correctly across a wide
<p>Or we can keep old memory around, and reuse it in a pool to save time. variety of hardware and operating systems, including large
The old libstdc++-v2 used a memory pool, and so do we. As of 3.0, clusters. The <code>__gnu_cxx::new_allocator</code> implements
<a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00136.html">it's the simple operator new and operator delete semantics, while <code>__gnu_cxx::malloc_allocator</code> implements much the same thing, only with the C language functions <code>std::malloc</code> and <code>std::free</code>.
on by default</a>. The pool is shared among all the containers in the </p>
program: when your program's std::vector&lt;int&gt; gets cut in half
and frees a bunch of its storage, that memory can be reused by the <p> Another approach is to use intelligence within the allocator class
private std::list&lt;WonkyWidget&gt; brought in from a KDE library to cache allocations. This extra machinery can take a variety of
that you linked against. And we don't have to call operators new and forms: a bitmap index, an index into an exponentially increasing
delete to pass the memory on, either, which is a speed bonus. power-of-two-sized buckets, or simpler fixed-size pooling cache. The
<strong>BUT</strong>... cache is shared among all the containers in the program: when your
</p> program's std::vector&lt;int&gt; gets cut in half and frees a bunch of
<p>What about threads? No problem: in a threadsafe environment, the its storage, that memory can be reused by the private
memory pool is manipulated atomically, so you can grow a container in std::list&lt;WonkyWidget&gt; brought in from a KDE library that you
one thread and shrink it in another, etc. <strong>BUT</strong> what linked against. And operators new and delete are not always called to
if threads in libstdc++ aren't set up properly? pass the memory on, either, which is a speed bonus. Examples of
<a href="../faq/index.html#5_6">That's been answered already</a>. allocators that use these techniques
</p> are <code>__gnu_cxx::bitmap_allocator</code>, <code>__gnu_cxx::pool_allocator</code>,
<p><strong>BUT</strong> what if you want to use your own allocator? What and <code>__gnu_cxx::__mt_alloc</code>.
if you plan on using a runtime-loadable version of malloc() which uses </p>
shared telepathic anonymous mmap'd sections serializable over a
network, so that memory requests <em>should</em> go through malloc? <p>Depending on the implementation techniques used, the underlying
And what if you need to debug it? operating system, and compilation environment, scaling caching
allocators can be tricky. In particular, order-of-destruction and
order-of-creation for memory pools may be difficult to pin down with
certainty, which may create problems when used with plugins or loading
and unloading shared objects in memory. As such, using caching
allocators on systems that do not
support <code>abi::__cxa_atexit</code> is not recommended.
</p>
<p>Versions of libstdc++ prior to 3.4 cache allocations in a memory
pool, instead of passing through to call the global allocation
operators (ie, <code>__gnu_cxx::pool_allocator</code>). More
recent versions default to the
simpler <code>__gnu_cxx::new_allocator</code>.
</p> </p>
<h3 class="left"> <h3 class="left">
...@@ -335,6 +348,11 @@ ...@@ -335,6 +348,11 @@
<td>&lt;ext/array_allocator.h&gt;</td> <td>&lt;ext/array_allocator.h&gt;</td>
<td>4.0.0</td> <td>4.0.0</td>
</tr> </tr>
<tr>
<td>__gnu_cxx::throw_allocator&lt;T&gt;</td>
<td>&lt;ext/throw_allocator.h&gt;</td>
<td>4.2.0</td>
</tr>
</table> </table>
<p>More details on each of these extension allocators follows. </p> <p>More details on each of these extension allocators follows. </p>
...@@ -371,6 +389,12 @@ ...@@ -371,6 +389,12 @@
size is checked, and assert() is used to guarantee they match. size is checked, and assert() is used to guarantee they match.
</p> </p>
</li> </li>
<li><code>throw_allocator</code>
<p> Includes memory tracking and marking abilities as well as hooks for
throwing exceptinos at configurable intervals (including random,
all, none).
</p>
</li>
<li><code>__pool_alloc</code> <li><code>__pool_alloc</code>
<p> A high-performance, single pool allocator. The reusable <p> A high-performance, single pool allocator. The reusable
memory is shared among identical instantiations of this type. memory is shared among identical instantiations of this type.
......
libstdc++-v3/docs/html/documentation.html
...@@ -26,7 +26,7 @@ href="http://gcc.gnu.org/libstdc++">project</a> to implement the ISO ...@@ -26,7 +26,7 @@ href="http://gcc.gnu.org/libstdc++">project</a> to implement the ISO
annex D, extensions as described by TR1, and future C++ library annex D, extensions as described by TR1, and future C++ library
standards still in progress. For those who want to see exactly how far standards still in progress. For those who want to see exactly how far
the project has come, or just want the latest bleeding-edge code, the the project has come, or just want the latest bleeding-edge code, the
up-to-date source is always publically available over anonymous SVN, up-to-date source is always publicly available over anonymous SVN,
and can be browsed over the <a and can be browsed over the <a
href="http://gcc.gnu.org/svn.html">web</a>. href="http://gcc.gnu.org/svn.html">web</a>.
</p> </p>
...@@ -34,13 +34,6 @@ href="http://gcc.gnu.org/svn.html">web</a>. ...@@ -34,13 +34,6 @@ href="http://gcc.gnu.org/svn.html">web</a>.
<p>Stable versions of libstdc++ are included with releases of <p>Stable versions of libstdc++ are included with releases of
<a href="http://gcc.gnu.org/releases.html">the GCC compilers</a>. <a href="http://gcc.gnu.org/releases.html">the GCC compilers</a>.
</p> </p>
<!--
The list below is automatically generated. To make changes in the text,
edit the appropriate HOWTO file and run "make" in this directory. In
those files, you may reorder entries as you like, but DO NOT change the
"#number"s in anchors, for they are used elsewhere and in bookmarks.
-->
<!-- beginlist -->
<ul> <ul>
<li>Introduction <li>Introduction
<ul> <ul>
...@@ -77,26 +70,27 @@ href="http://gcc.gnu.org/svn.html">web</a>. ...@@ -77,26 +70,27 @@ href="http://gcc.gnu.org/svn.html">web</a>.
<ul> <ul>
<li>Header Files <li>Header Files
<ul> <ul>
<li><a href="17_intro/howto.html#2.1">Available headers</a></li> <li><a href="17_intro/howto.html#2.0">Available headers</a></li>
<li><a href="17_intro/howto.html#2.2">Headers and <code>namespace std</code></a></li> <li><a href="17_intro/howto.html#2.1">Mixing headers</a></li>
<li>Pre-compiled headers</li> <li><a href="17_intro/howto.html#2.2">The C Headers and <code>namespace std</code></a></li>
<li><a href="17_intro/howto.html#2.3">Precompiled Headers</a></li>
</ul> </ul>
</li> </li>
<li>Namespaces <li>Namespaces
<ul> <ul>
<li><a href="17_intro/howto.html#2.5">Namespace <code>std::</code></a></li> <li><a href="17_intro/howto.html#3.0">Available namespaces</li>
<li><a href="17_intro/howto.html#2.6">Using namespace composition</a></li> <li><a href="17_intro/howto.html#3.1">Namespace <code>std::</code></a></li>
<li><a href="17_intro/howto.html#3.2">Using namespace composition</a></li>
</ul> </ul>
</li> </li>
<li><a href="17_intro/howto.html#6">Macros</a></li> <li><a href="17_intro/howto.html#6">Macros</a></li>
<li>Command line options</li>
<li>Concurrency <li>Concurrency
<ul> <ul>
<li>Atomic Operations</li>
<li><a href="17_intro/howto.html#3">Thread safety overview</a></li>
<li><a href="faq/index.html#5_6">Is it thread safe?</a></li> <li><a href="faq/index.html#5_6">Is it thread safe?</a></li>
<li><a href="17_intro/howto.html#7">Thread safety history and evolution</a></li>
<li><a href="23_containers/howto.html#3">Containers</a></li> <li><a href="23_containers/howto.html#3">Containers</a></li>
<li><a href="27_io/howto.html#9">IO</a></li> <li><a href="27_io/howto.html#9">IO</a></li>
</ul> </ul>
...@@ -122,8 +116,15 @@ href="http://gcc.gnu.org/svn.html">web</a>. ...@@ -122,8 +116,15 @@ href="http://gcc.gnu.org/svn.html">web</a>.
<li>Diagnostics <li>Diagnostics
<ul> <ul>
<li>Exceptions
<ul>
<li>Exception class hierarchy</li> <li>Exception class hierarchy</li>
<li><a href="19_diagnostics/howto.html#1">Adding data to exceptions</a></li> <li><a href="19_diagnostics/howto.html#1">Adding data to exceptions</a></li>
<li>Cancellation</li>
</ul>
</li>
<li><a href="19_diagnostics/howto.html#3">Concept checking</a></li> <li><a href="19_diagnostics/howto.html#3">Concept checking</a></li>
</ul> </ul>
</li> </li>
...@@ -248,6 +249,7 @@ href="http://gcc.gnu.org/svn.html">web</a>. ...@@ -248,6 +249,7 @@ href="http://gcc.gnu.org/svn.html">web</a>.
</ul> </ul>
</li> </li>
<li><a href="ext/../18_support/howto.html#6">Demangling</a></li> <li><a href="ext/../18_support/howto.html#6">Demangling</a></li>
<li><a href="ext/concurrence.html">Concurrency: Threads and Atomics</a></li>
</ul> </ul>
</li> </li>
...@@ -277,6 +279,7 @@ href="http://gcc.gnu.org/svn.html">web</a>. ...@@ -277,6 +279,7 @@ href="http://gcc.gnu.org/svn.html">web</a>.
<li><a href="17_intro/porting.html">Porting to new hardware or operating systems.</a></li> <li><a href="17_intro/porting.html">Porting to new hardware or operating systems.</a></li>
<li><a href="17_intro/abi.html">ABI Policy and Guidelines</a></li> <li><a href="17_intro/abi.html">ABI Policy and Guidelines</a></li>
<li><a href="17_intro/api.html">API Evolution and Deprecation History</a></li> <li><a href="17_intro/api.html">API Evolution and Deprecation History</a></li>
<li><a href="17_intro/backwards_compatibility.html">Backwards Compatibility</a></li>
</ul> </ul>
</li> </li>
......
libstdc++-v3/docs/html/ext/concurrence.html 0 → 100644
<?xml version="1.0" encoding="ISO-8859-1"?>
<!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" xml:lang="en" lang="en">
<head>
<meta name="AUTHOR" content="bkoz@gcc.gnu.org (Benjamin Kosnik)" />
<meta name="KEYWORDS" content="C++, libstdc++, MT, thread, pthread, mutex, loc, atomic" />
<meta name="DESCRIPTION" content="Concurrency Support" />
<meta name="GENERATOR" content="emacs and ten fingers" />
<title>Concurrency Support</title>
<link rel="StyleSheet" href="lib3styles.css" type="text/css" />
<link rel="Start" href="documentation.html" type="text/html"
title="GNU C++ Standard Library" />
<link rel="Copyright" href="17_intro/license.html" type="text/html" />
</head>
<body>
<h1 class="centered"><a name="top">Concurrency Support</a></h1>
<p class="fineprint"><em>
The latest version of this document is always available at
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/concurrence.html">
http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/concurrence.html</a>.
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
<!-- ####################################################### -->
<hr />
<p>The interface for concurrency support is divided into two files:
&lt;ext/atomicity.h&gt; which provides support for atomic operations,
and &lt;ext/concurrence.h&gt;, which provides mutex and lock objects
as well as compile-time data structures for querying thread
support.</p>
<p>It is expected that support for concurrence will evolve into what
is specified in the draft C++0x standard.</p>
<h3 class="left">
<a name="atomic_api">Atomics Interface</a>
</h3>
<p>
Two functions and one type form the base of atomic support.
</p>
<p>The type <code>_Atomic_word</code> is a signed integral type
supporting atomic operations.
</p>
<p>
The two functions functions are:
</p>
<pre>
_Atomic_word
__exchange_and_add_dispatch(volatile _Atomic_word*, int);
void
__atomic_add_dispatch(volatile _Atomic_word*, int);
</pre>
<p>Both of these functions are declared in the header file
&lt;ext/atomicity.h&gt;, and are in <code>namespace __gnu_cxx</code>.
</p>
<ul>
<li>
<code>
__exchange_and_add_dispatch
</code>
<p>Adds the second argument's value to the first argument. Returns the old value.
</p>
</li>
<li>
<code>
__atomic_add_dispatch
</code>
<p>Adds the second argument's value to the first argument. Has no return value.
</p>
</li>
</ul>
</p>
These functions forward to one of several specialized helper
functions, depending on the circumstances. For instance,
</p>
<p>
<code>
__exchange_and_add_dispatch
</code>
</p>
<p>
Calls through to either of:
</p>
<ul>
<li><code>__exchange_and_add</code>
<p>Multi-thread version. Inlined if compiler-generated builtin atomics
can be used, otherwise resolved at link time to a non-builtin code
sequence.
</p>
</li>
<li><code>__exchange_and_add_single</code>
<p>Single threaded version. Inlined.</p>
</li>
</ul>
<p>However, only <code>__exchange_and_add_dispatch</code>
and <code>__atomic_add_dispatch</code> should be used. These functions
can be used in a portable manner, regardless of the specific
environment. They are carefully designed to provide optimum efficiency
and speed, abstracting out atomic accesses when they are not required
(even on hosts that support compiler intrinsics for atomic
operations.)
</p>
<p>
In addition, there are two macros
</p>
<p>
<code>
_GLIBCXX_READ_MEM_BARRIER
</code>
</p>
<p>
<code>
GLIBCXX_WRITE_MEM_BARRIER
</code>
</p>
<p>
Which expand to the appropriate write and read barrier required by the
host hardware and operating system.
</p>
<h3 class="left">
<a name="pthread_api">Pthread Interface</a>
</h3>
<p>A thin layer above IEEE 1003.1 (ie pthreads) is used to abastract
the thread interface for GCC. This layer is called "gthread," and is
comprised of one header file that wraps the host's default thread layer with
a POSIX-like interfaces.
</p>
<p> The file &lt;gthr-default.h&gt; points to the deduced wrapper for
the current host. In libstdc++ implementation files,
&lt;bits/gthr.h&gt; is used to select the proper gthreads file.
</p>
<p>Within libstdc++ sources, all calls to underlying thread functionality
use this layer. More detail as to the specific interface can be found in the source <a href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/gthr_8h-source.html">documentation</a>.
</p>
<p>By design, the gthread layer is interoperable with the types,
functions, and usage found in the usual &lt;pthread.h&gt; file,
including <code>pthread_t</code>, <code>pthread_once_t</code>, <code>pthread_create</code>,
etc.
</p>
<h3 class="left">
<a name="concur_api">Concurrence Interface</a>
</h3>
<p>The file &lt;ext/concurrence.h&gt; contains all the higher-level
constructs for playing with threads. In contrast to the atomics layer,
the concurrence layer consists largely of types. All types are defined within <code>namespace __gnu_cxx</code>.
</p>
<p>
These types can be used in a portable manner, regardless of the
specific environment. They are carefully designed to provide optimum
efficiency and speed, abstracting out underlying thread calls and
accesses when compiling for single-threaded situations (even on hosts
that support multiple threads.)
</p>
<p>The enumerated type <code>_Lock_policy</code> details the set of
available locking
policies: <code>_S_single</code>, <code>_S_mutex</code>,
and <code>_S_atomic</code>.
</p>
<ul>
<li><code>_S_single</code>
<p>Indicates single-threaded code that does not need locking.
</p>
</li>
<li><code>_S_mutex</code>
<p>Indicates multi-threaded code using thread-layer abstractions.
</p>
</li>
<li><code>_S_atomic</code>
<p>Indicates multi-threaded code using atomic operations.
</p>
</li>
</ul>
<p>The compile-time constant <code>__default_lock_policy</code> is set
to one of the three values above, depending on characteristics of the
host environment and the current compilation flags.
</p>
<p>Two more datatypes make up the rest of the
interface: <code>__mutex</code>, and <code>__scoped_lock</code>.
</p>
<p>
</p>
<p>The scoped lock idiom is well-discussed within the C++
community. This version takes a <code>__mutex</code> reference, and
locks it during construction of <code>__scoped_locke</code> and
unlocks it during destruction. This is an efficient way of locking
critical sections, while retaining exception-safety.
</p>
<p>Typical usage of the last two constructs is demonstrated as follows:
</p>
<pre>
#include &lt;ext/concurrence.h&gt;
namespace
{
__gnu_cxx::__mutex safe_base_mutex;
} // anonymous namespace
namespace other
{
void
foo()
{
__gnu_cxx::__scoped_lock sentry(safe_base_mutex);
for (int i = 0; i < max; ++i)
{
_Safe_iterator_base* __old = __iter;
__iter = __iter->_M_next;
__old->_M_detach_single();
}
}
</pre>
<p>In this sample code, an anonymous namespace is used to keep
the <code>__mutex</code> private to the compilation unit,
and <code>__scoped_lock</code> is used to guard access to the critical
section within the for loop, locking the mutex on creation and freeing
the mutex as control moves out of this block.
</p>
<p>Several exception classes are used to keep track of
concurrence-related errors. These classes
are: <code>__concurrence_lock_error</code>, <code>__concurrence_unlock_error</code>, <code>__concurrence_wait_error</code>,
and <code>__concurrence_broadcast_error</code>.
</p>
<h3 class="left">
<a name="atomic_impl">Details on builtin atomic support and library fallbacks</a>
</h3>
<p>The functions for atomic operations described above are either
implemented via compiler intrinsics (if the underlying host is
capable) or by library fallbacks.</p>
<p>Compiler intrinsics (builtins) are always preferred. However, as
the compiler builtins for atomics are not universally implemented,
using them directly is problematic, and can result in undefined
function calls. (An example of an undefined symbol from the use
of <code>__sync_fetch_and_add</code> on an unsupported host is a
missing reference to <code>__sync_fetch_and_add_4</code>.)
</p>
<p>In addition, on some hosts the compiler intrinsics are enabled
conditionally, via the <code>-march</code> command line flag. This makes
usage vary depending on the target hardware and the flags used during
compile.
</p>
<p> If builtins are possible, <code>_GLIBCXX_ATOMIC_BUILTINS</code>
will be defined.
</p>
<p>For the following hosts, intrinsics are enabled by default.
</p>
<ul>
<li>alpha</li>
<li>ia64</li>
<li>powerpc</li>
<li>s390</li>
</ul>
<p>For others, some form of <code>-march</code> may work. On
non-ancient x86 hardware, <code>-march=native</code> usually does the
trick.</p>
<p> For hosts without compiler intrinsics, but with capable
hardware, hand-crafted assembly is selected. This is the case for the following hosts:
</p>
<ul>
<li>cris</li>
<li>hppa</li>
<li>i386</li>
<li>i486</li>
<li>m48k</li>
<li>mips</li>
<li>sparc</li>
</ul>
<p>And for the rest, a simulated atomic lock via pthreads.
</p>
<p> Detailed information about compiler intrinsics for atomic operations can be found in the GCC <a href="http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html"> documentation</a>.
</p>
<p> More details on the library fallbacks from the porting <a href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/porting.html#Thread%20safety">section</a>.
</p>
</body>
</html>
libstdc++-v3/docs/html/ext/howto.html
...@@ -74,18 +74,13 @@ ...@@ -74,18 +74,13 @@
are deprecated but available as backwards-compatible extensions, are deprecated but available as backwards-compatible extensions,
as discussed further below. <code>&lt;rope&gt;</code> is the as discussed further below. <code>&lt;rope&gt;</code> is the
SGI specialization for large strings (&quot;rope,&quot; SGI specialization for large strings (&quot;rope,&quot;
&quot;large strings,&quot; get it? love those SGI folks). &quot;large strings,&quot; get it? Love that geeky humor.)
<code>&lt;slist&gt;</code> is a singly-linked list, for when the <code>&lt;slist&gt;</code> is a singly-linked list, for when the
doubly-linked <code>list&lt;&gt;</code> is too much space doubly-linked <code>list&lt;&gt;</code> is too much space
overhead, and <code>&lt;rb_tree&gt;</code> exposes the red-black overhead, and <code>&lt;rb_tree&gt;</code> exposes the red-black
tree classes used in the implementation of the standard maps and tree classes used in the implementation of the standard maps and
sets. sets.
</p> </p>
<p>Okay, about those hashing classes... these classes have been
deprecated by the unordered_set, unordered_multiset, unordered_map,
unordered_multimap containers in TR1 and the upcoming C++0x, and
may be removed in future releases.
</p>
<p>Each of the associative containers map, multimap, set, and multiset <p>Each of the associative containers map, multimap, set, and multiset
have a counterpart which uses a have a counterpart which uses a
<a href="http://www.sgi.com/tech/stl/HashFunction.html">hashing <a href="http://www.sgi.com/tech/stl/HashFunction.html">hashing
...@@ -111,11 +106,13 @@ ...@@ -111,11 +106,13 @@
components, and if you aren't scared about the possibility of components, and if you aren't scared about the possibility of
pathological cases, you'll probably get better performance from pathological cases, you'll probably get better performance from
hash_map.</em></blockquote> hash_map.</em></blockquote>
<p>(Side note: for those of you wondering, <strong>&quot;Why wasn't a hash
table included in the Standard in the first #!$@ place?&quot;</strong> <p>Okay, about the SGI hashing classes... these classes have been
I'll give a quick answer: it was proposed, but too late and in too deprecated by the unordered_set, unordered_multiset, unordered_map,
unorganized a fashion.) unordered_multimap containers in TR1 and the upcoming C++0x, and
may be removed in future releases.
</p> </p>
<p>Return <a href="#top">to top of page</a> or <p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>. <a href="../faq/index.html">to the FAQ</a>.
</p> </p>
......
libstdc++-v3/docs/html/ext/sgiexts.html
...@@ -9,7 +9,7 @@ ...@@ -9,7 +9,7 @@
<meta name="KEYWORDS" content="libstdc++, libstdc++, GCC, g++, STL, SGI" /> <meta name="KEYWORDS" content="libstdc++, libstdc++, GCC, g++, STL, SGI" />
<meta name="DESCRIPTION" content="SGI extensions preserved in libstdc++." /> <meta name="DESCRIPTION" content="SGI extensions preserved in libstdc++." />
<meta name="GENERATOR" content="vi and eight fingers" /> <meta name="GENERATOR" content="vi and eight fingers" />
<title>SGI extensions to the library in libstdc++</title> <title>HP/SGI STL extensions</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" /> <link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html" <link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" /> title="GNU C++ Standard Library" />
...@@ -19,29 +19,29 @@ ...@@ -19,29 +19,29 @@
</head> </head>
<body> <body>
<h1 class="centered"><a name="top">SGI extensions to the library in <h1 class="centered"><a name="top">HP/SGI STL extensions</a></h1>
libstdc++</a></h1>
<p>This page describes the extensions that SGI made to their version of the <p>This page describes the extensions that SGI made to the STL subset
STL subset of the Standard C++ Library. For a time we of the Standard C++ Library, which also includes work from the
<a href="../faq/index.html#5_3">tracked and imported changes and updates originating HP codebase. This work is the basis for much of
from most of the SGI STL</a>, up through their (apparently) final release. libstdc++, and where possible these extensions have been
Their extensions were mostly preserved. preserved.
</p> </p>
<p>They are listed according to the chapters of the library that they <p>What follows is a listing of these extensions, according to the
extend (see <a href="../documentation.html#3">the chapter-specific notes</a> chapters of the library that they extend
for a description). Not every chapter may have extensions, and the (see <a href="../documentation.html#3">the chapter-specific
extensions may come and go. Also, this page is incomplete because the notes</a> for a description). Not every chapter has extensions,
author is pressed for time. Check back often; the latest change was on and existing extensions may be removed (or moved) as their
$Date: 2003/04/16 17:02:47 $ (UTC). functionality is standardized.
</p> </p>
<p>Descriptions range from the scanty to the verbose. You should also check <p>Descriptions range from the scanty to the verbose. Also check
the <a href="../documentation.html#4">generated documentation</a> for notes the <a href="../documentation.html#4">generated documentation</a>
and comments, especially for entries marked with '*'. For more complete for notes and comments, especially for entries marked with '*'.
doumentation, see the SGI website. For <em>really</em> complete For more complete doumentation, see the SGI website.
documentation, buy a copy of Matt Austern's book. *grin* For <em>really</em> complete documentation, consider perusing a
copy of Matt Austern's book "Generic Programming and the STL."
</p> </p>
<p>Back to the <a href="howto.html">libstdc++ extensions</a>. <p>Back to the <a href="howto.html">libstdc++ extensions</a>.
......
libstdc++-v3/docs/html/faq/index.html
...@@ -1052,14 +1052,26 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff ...@@ -1052,14 +1052,26 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
<hr /> <hr />
<h2><a name="5_6">5.6 Is libstdc++ thread-safe?</a></h2> <h2><a name="5_6">5.6 Is libstdc++ thread-safe?</a></h2>
<p>libstdc++ strives to be thread-safe when all of the following <p>The library strives to be thread-safe when all of the following
conditions are met: conditions are met:
</p> </p>
<ul> <ul>
<li>The system's libc is itself thread-safe,</li> <li>The system's libc is itself thread-safe,</li>
<li><code>gcc -v</code> reports a thread model other than 'single',</li> <li>The compiler in use reports a thread model other than 'single'. This can be tested via output from <code>gcc -v</code>. Multi-thread capable versions of gcc output something like this:
<li>[pre-3.3 only] a non-generic implementation of atomicity.h <pre>
exists for the architecture in question.</li> %gcc -v
Using built-in specs.
...
Thread model: posix
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
</pre>
<p>Look for "Thread model" lines that aren't equal to "single."</p>
</li>
<li>Requisite command-line flags are used for atomic operations and threading. Examples of this include <code>-pthread</code> and <code>-march=native</code>, although specifics vary depending on the host environment. See <a href="http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html">Machine Dependent Options</a>.</li>
<li>An implementation of atomicity.h functions
exists for the architecture in question. See the internals documentation for more <a href="../ext/concurrence.html">details</a>.</li>
</ul> </ul>
<p>The user-code must guard against concurrent method calls which may <p>The user-code must guard against concurrent method calls which may
access any particular library object's state. Typically, the access any particular library object's state. Typically, the
......
libstdc++-v3/include/precompiled/stdc++.h
// C++ includes used for precompiling -*- C++ -*- // C++ includes used for precompiling -*- C++ -*-
// Copyright (C) 2003 Free Software Foundation, Inc. // Copyright (C) 2003, 2007 Free Software Foundation, Inc.
// //
// This file is part of the GNU ISO C++ Library. This library is free // This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the // software; you can redistribute it and/or modify it under the
...@@ -51,6 +51,17 @@ ...@@ -51,6 +51,17 @@
#include <cstring> #include <cstring>
#include <ctime> #include <ctime>
#ifdef __GXX_EXPERIMENTAL_CXX0X__
#include <ccomplex>
#include <cfenv>
#include <cinttypes>
#include <cstdbool>
#include <cstdint>
#include <ctgmath>
#include <cwchar>
#include <cwctype>
#endif
// C++ // C++
#include <algorithm> #include <algorithm>
#include <bitset> #include <bitset>
...@@ -84,3 +95,14 @@ ...@@ -84,3 +95,14 @@
#include <utility> #include <utility>
#include <valarray> #include <valarray>
#include <vector> #include <vector>
#ifdef __GXX_EXPERIMENTAL_CXX0X__
#include <array>
#include <random>
#include <regex>
#include <system_error>
#include <tuple>
#include <type_traits>
#include <unordered_map>
#include <unordered_set>
#endif
libstdc++-v3/testsuite/17_intro/headers/c++200x/all.cc
...@@ -121,6 +121,7 @@ ...@@ -121,6 +121,7 @@
#include <stdexcept> #include <stdexcept>
#include <streambuf> #include <streambuf>
#include <string> #include <string>
#include <system_error>
#include <tuple> #include <tuple>
#include <typeinfo> #include <typeinfo>
#include <type_traits> #include <type_traits>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment