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 498 additions and 79 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/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