git
/
gcc
mirror of git://gcc.gnu.org/git/gcc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

extensions.xml: Improve markup and note that some extensions are included in C++11. 

* doc/xml/manual/extensions.xml: Improve markup and note that some
	extensions are included in C++11.
	* doc/xml/manual/concurrency_extensions.xml: Likewise.

From-SVN: r182742
This commit is contained in:
Jonathan Wakely 2011-12-30 13:46:18 +00:00 committed by Jonathan Wakely
parent f32fd5aaec
commit 84de2982de
3 changed files with 61 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
libstdc++-v3/ChangeLog
View File

@ -1,3 +1,9 @@
2011-12-30 Jonathan Wakely <jwakely.gcc@gmail.com>
* doc/xml/manual/extensions.xml: Improve markup and note that some
extensions are included in C++11.
* doc/xml/manual/concurrency_extensions.xml: Likewise.
2011-12-30 Paolo Carlini <paolo.carlini@oracle.com> 2011-12-30 Paolo Carlini <paolo.carlini@oracle.com>
PR libstdc++/51711 PR libstdc++/51711

11
libstdc++-v3/doc/xml/manual/concurrency_extensions.xml
View File

@ -21,7 +21,8 @@
<section xml:id="manual.ext.concurrency.design.threads" xreflabel="Threads API"><info><title>Interface to Locks and Mutexes</title></info> <section xml:id="manual.ext.concurrency.design.threads" xreflabel="Threads API"><info><title>Interface to Locks and Mutexes</title></info>
<para>The file &lt;ext/concurrence.h&gt; contains all the higher-level <para>The file <filename class="headerfile">&lt;ext/concurrence.h&gt;</filename>
contains all the higher-level
constructs for playing with threads. In contrast to the atomics layer, 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>. the concurrence layer consists largely of types. All types are defined within <code>namespace __gnu_cxx</code>.
</para> </para>
@ -65,14 +66,14 @@ host environment and the current compilation flags.
interface: <code>__mutex</code>, and <code>__scoped_lock</code>. interface: <code>__mutex</code>, and <code>__scoped_lock</code>.
</para> </para>
<para>
</para>
<para>The scoped lock idiom is well-discussed within the C++ <para>The scoped lock idiom is well-discussed within the C++
community. This version takes a <code>__mutex</code> reference, and community. This version takes a <code>__mutex</code> reference, and
locks it during construction of <code>__scoped_locke</code> and locks it during construction of <code>__scoped_lock</code> and
unlocks it during destruction. This is an efficient way of locking unlocks it during destruction. This is an efficient way of locking
critical sections, while retaining exception-safety. critical sections, while retaining exception-safety.
These types have been superseded in the ISO C++ 2011 standard by the
mutex and lock types defined in the header
<filename class="headerfile">&lt;mutex&gt;</filename>.
</para> </para>
</section> </section>

85
libstdc++-v3/doc/xml/manual/extensions.xml
View File

@ -160,7 +160,7 @@ extensions, be aware of two things:
<para>There are <para>There are
versions of single-bit test, set, reset, and flip member functions which versions of single-bit test, set, reset, and flip member functions which
do no range-checking. If we call them member functions of an instantiation do no range-checking. If we call them member functions of an instantiation
of "bitset&lt;N&gt;," then their names and signatures are: of <code>bitset&lt;N&gt;</code>, then their names and signatures are:
</para> </para>
<programlisting> <programlisting>
bitset&lt;N&gt;&amp; _Unchecked_set (size_t pos); bitset&lt;N&gt;&amp; _Unchecked_set (size_t pos);
@ -173,14 +173,10 @@ extensions, be aware of two things:
no present plans to do so (and there doesn't seem to be any immediate no present plans to do so (and there doesn't seem to be any immediate
reason to). reason to).
</para> </para>
<para>The semantics of member function <code>operator[]</code> are not specified <para>The member function <code>operator[]</code> on a const bitset returns
in the C++ standard. A long-standing defect report calls for sensible a bool, and for a non-const bitset returns a <code>reference</code> (a
obvious semantics, which are already implemented here: <code>op[]</code> nested type). No range-checking is done on the index argument, in keeping
on a const bitset returns a bool, and for a non-const bitset returns a with other containers' <code>operator[]</code> requirements.
<code>reference</code> (a nested type). However, this implementation does
no range-checking on the index argument, which is in keeping with other
containers' <code>op[]</code> requirements. The defect report's proposed
resolution calls for range-checking to be done. We'll just wait and see...
</para> </para>
<para>Finally, two additional searching functions have been added. They return <para>Finally, two additional searching functions have been added. They return
the index of the first "on" bit, and the index of the first the index of the first "on" bit, and the index of the first
@ -214,16 +210,20 @@ extensions, be aware of two things:
&lt;rb_tree&gt; &lt;rb_tree&gt;
</programlisting> </programlisting>
<para>are all here; <para>are all here;
<code>&lt;hash_map&gt;</code> and <code>&lt;hash_set&gt;</code> <filename class="headerfile">&lt;backwards/hash_map&gt;</filename> and
<filename class="headerfile">&lt;backwards/hash_set&gt;</filename>
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.
SGI specialization for large strings ("rope," <filename class="headerfile">&lt;ext/rope&gt;</filename> is the SGI
"large strings," get it? Love that geeky humor.) specialization for large strings ("rope," "large strings," get it? Love
<code>&lt;slist&gt;</code> is a singly-linked list, for when the that geeky humor.)
doubly-linked <code>list&lt;&gt;</code> is too much space <filename class="headerfile">&lt;ext/slist&gt;</filename> (superseded in
overhead, and <code>&lt;rb_tree&gt;</code> exposes the red-black C++11 by <filename class="headerfile">&lt;forward_list&gt;</filename>)
tree classes used in the implementation of the standard maps and is a singly-linked list, for when the doubly-linked <code>list&lt;&gt;</code>
sets. is too much space overhead, and
<filename class="headerfile">&lt;ext/rb_tree&gt;</filename> exposes the
red-black tree classes used in the implementation of the standard maps
and sets.
</para> </para>
<para>Each of the associative containers map, multimap, set, and multiset <para>Each of the associative containers map, multimap, set, and multiset
have a counterpart which uses a have a counterpart which uses a
@ -256,6 +256,13 @@ extensions, be aware of two things:
</para> </para>
</blockquote> </blockquote>
<para>
The deprecated hash tables are superseded by the standard unordered
associative containers defined in the ISO C++ 2011 standard in the
headers <filename class="headerfile">&lt;unordered_map&gt;</filename>
and <filename class="headerfile">&lt;unordered_set&gt;</filename>.
</para>
</section> </section>
</chapter> </chapter>
@ -264,36 +271,37 @@ extensions, be aware of two things:
<?dbhtml filename="ext_utilities.html"?> <?dbhtml filename="ext_utilities.html"?>
<para> <para>
The &lt;functional&gt; header contains many additional functors The <filename class="headerfile">&lt;functional&gt;</filename> header
contains many additional functors
and helper functions, extending section 20.3. They are and helper functions, extending section 20.3. They are
implemented in the file stl_function.h: implemented in the file stl_function.h:
</para> </para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para><code>identity_element</code> for addition and multiplication. * <para><code>identity_element</code> for addition and multiplication.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para>The functor <code>identity</code>, whose <code>operator()</code> <para>The functor <code>identity</code>, whose <code>operator()</code>
returns the argument unchanged. * returns the argument unchanged.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para>Composition functors <code>unary_function</code> and <para>Composition functors <code>unary_function</code> and
<code>binary_function</code>, and their helpers <code>compose1</code> <code>binary_function</code>, and their helpers <code>compose1</code>
and <code>compose2</code>. * and <code>compose2</code>.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para><code>select1st</code> and <code>select2nd</code>, to strip pairs. * <para><code>select1st</code> and <code>select2nd</code>, to strip pairs.
</para> </para>
</listitem> </listitem>
<listitem><para><code>project1st</code> and <code>project2nd</code>. * </para></listitem> <listitem><para><code>project1st</code> and <code>project2nd</code>. </para></listitem>
<listitem><para>A set of functors/functions which always return the same result. They <listitem><para>A set of functors/functions which always return the same result. They
are <code>constant_void_fun</code>, <code>constant_binary_fun</code>, are <code>constant_void_fun</code>, <code>constant_binary_fun</code>,
<code>constant_unary_fun</code>, <code>constant0</code>, <code>constant_unary_fun</code>, <code>constant0</code>,
<code>constant1</code>, and <code>constant2</code>. * </para></listitem> <code>constant1</code>, and <code>constant2</code>. </para></listitem>
<listitem><para>The class <code>subtractive_rng</code>. * </para></listitem> <listitem><para>The class <code>subtractive_rng</code>. </para></listitem>
<listitem><para>mem_fun adaptor helpers <code>mem_fun1</code> and <listitem><para>mem_fun adaptor helpers <code>mem_fun1</code> and
<code>mem_fun1_ref</code> are provided for backwards compatibility. </para></listitem> <code>mem_fun1_ref</code> are provided for backwards compatibility. </para></listitem>
</itemizedlist> </itemizedlist>
@ -320,11 +328,11 @@ you can also use
get_temporary_buffer(5, (int*)0); get_temporary_buffer(5, (int*)0);
</programlisting> </programlisting>
<para> <para>
A class <code>temporary_buffer</code> is given in stl_tempbuf.h. * A class <code>temporary_buffer</code> is given in stl_tempbuf.h.
</para> </para>
<para> <para>
The specialized algorithms of section 20.4.4 are extended with The specialized algorithms of section 20.4.4 are extended with
<code>uninitialized_copy_n</code>. * <code>uninitialized_copy_n</code>.
</para> </para>
</chapter> </chapter>
@ -371,25 +379,30 @@ get_temporary_buffer(5, (int*)0);
<chapter xml:id="manual.ext.numerics" xreflabel="Numerics"><info><title>Numerics</title></info> <chapter xml:id="manual.ext.numerics" xreflabel="Numerics"><info><title>Numerics</title></info>
<?dbhtml filename="ext_numerics.html"?> <?dbhtml filename="ext_numerics.html"?>
<para>26.4, the generalized numeric operations such as accumulate, are extended <para>26.4, the generalized numeric operations such as <code>accumulate</code>,
with the following functions: are extended with the following functions:
</para> </para>
<programlisting> <programlisting>
power (x, n); power (x, n);
power (x, n, moniod_operation);</programlisting> power (x, n, monoid_operation);</programlisting>
<para>Returns, in FORTRAN syntax, "x ** n" where n&gt;=0. In the <para>Returns, in FORTRAN syntax, "<code>x ** n</code>" where
case of n == 0, returns the identity element for the <code>n &gt;= 0</code>. In the
case of <code>n == 0</code>, returns the identity element for the
monoid operation. The two-argument signature uses multiplication (for monoid operation. The two-argument signature uses multiplication (for
a true "power" implementation), but addition is supported as well. a true "power" implementation), but addition is supported as well.
The operation functor must be associative. The operation functor must be associative.
</para> </para>
<para>The <code>iota</code> function wins the award for Extension With the <para>The <code>iota</code> function wins the award for Extension With the
Coolest Name. It "assigns sequentially increasing values to a range. Coolest Name (the name comes from Ken Iverson's APL language.) As
That is, it assigns value to *first, value + 1 to *(first + 1) and so described in the <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.sgi.com/tech/stl/iota.html">SGI
on." Quoted from SGI documentation. documentation</link>, it "assigns sequentially increasing values to a range.
That is, it assigns <code>value</code> to <code>*first</code>,
<code>value + 1</code> to<code> *(first + 1)</code> and so on."
</para> </para>
<programlisting> <programlisting>
void iota(_ForwardIter first, _ForwardIter last, _Tp value);</programlisting> void iota(_ForwardIter first, _ForwardIter last, _Tp value);</programlisting>
<para>The <code>iota</code> function is included in the ISO C++ 2011 standard.
</para>
</chapter> </chapter>
<!-- Chapter 12 : Iterators --> <!-- Chapter 12 : Iterators -->