howto.html: Add anchor name.
2001-09-25 Phil Edwards <pme@gcc.gnu.org> * docs/html/20_util/howto.html: Add anchor name. * docs/html/23_containers/howto.html: Line wrapping, another link. * docs/html/25_algorithms/howto.html: Another note. * docs/html/ext/howto.html: Link to SGI extensions. List DRs and link to them... * docs/html/ext/lwg-active.html: ...in this new file (from R19), * docs/html/ext/lwg-defects.html: and this new file (from R19). * docs/html/ext/sgiexts.html: New file. Mention SGI extensions carried over to libstdc++-v3. * docs/html/faq/index.html: Link to SGI extensions. Mention the "missing .." pseudobug. * docs/html/faq/index.txt: Regenerate. * include/bits/ios_base.h: DR-related comment cleanup. * include/bits/istream.tcc: Likewise. * include/bits/locale_facets.h: Likewise. * include/bits/locale_facets.tcc: Likewise. * include/bits/ostream.tcc: Likewise. * include/bits/std_bitset.h: Likewise. * include/bits/std_iosfwd.h: Likewise. * include/bits/std_istream.h: Likewise. * include/bits/std_ostream.h: Likewise. * include/bits/std_streambuf.h: Likewise. * include/bits/stl_pair.h: Likewise. * include/bits/streambuf_iterator.h: Likewise. * include/bits/std_map.h: Remove unused header inclusion guard _CPP_BITS_STL_TREE_H from around bits/stl_tree.h. * include/bits/std_set.h: Likewise. * include/bits/stl_function.h: Doxygen markup. * docs/doxygen/doxygroups.cc: New file, specifying module grouping. * libsupc++/typeinfo: Doxygen markup tweak. From-SVN: r45816
This commit is contained in:
Phil Edwards
parent
c176688132
commit
77cd227ec3
27 changed files with 12230 additions and 142 deletions
|
|
@ -1,3 +1,40 @@
|
|||
2001-09-25 Phil Edwards <pme@gcc.gnu.org>
|
||||
|
||||
* docs/html/20_util/howto.html: Add anchor name.
|
||||
* docs/html/23_containers/howto.html: Line wrapping, another link.
|
||||
* docs/html/25_algorithms/howto.html: Another note.
|
||||
|
||||
* docs/html/ext/howto.html: Link to SGI extensions. List DRs and
|
||||
link to them...
|
||||
* docs/html/ext/lwg-active.html: ...in this new file (from R19),
|
||||
* docs/html/ext/lwg-defects.html: and this new file (from R19).
|
||||
* docs/html/ext/sgiexts.html: New file. Mention SGI extensions
|
||||
carried over to libstdc++-v3.
|
||||
* docs/html/faq/index.html: Link to SGI extensions. Mention the
|
||||
"missing .." pseudobug.
|
||||
* docs/html/faq/index.txt: Regenerate.
|
||||
|
||||
* include/bits/ios_base.h: DR-related comment cleanup.
|
||||
* include/bits/istream.tcc: Likewise.
|
||||
* include/bits/locale_facets.h: Likewise.
|
||||
* include/bits/locale_facets.tcc: Likewise.
|
||||
* include/bits/ostream.tcc: Likewise.
|
||||
* include/bits/std_bitset.h: Likewise.
|
||||
* include/bits/std_iosfwd.h: Likewise.
|
||||
* include/bits/std_istream.h: Likewise.
|
||||
* include/bits/std_ostream.h: Likewise.
|
||||
* include/bits/std_streambuf.h: Likewise.
|
||||
* include/bits/stl_pair.h: Likewise.
|
||||
* include/bits/streambuf_iterator.h: Likewise.
|
||||
|
||||
* include/bits/std_map.h: Remove unused header inclusion guard
|
||||
_CPP_BITS_STL_TREE_H from around bits/stl_tree.h.
|
||||
* include/bits/std_set.h: Likewise.
|
||||
|
||||
* include/bits/stl_function.h: Doxygen markup.
|
||||
* docs/doxygen/doxygroups.cc: New file, specifying module grouping.
|
||||
* libsupc++/typeinfo: Doxygen markup tweak.
|
||||
|
||||
2001-09-20 Scott Johnston <scott@accom.com>
|
||||
Peter Schmid <schmid@snake.iap.physik.tu-darmstadt.de>
|
||||
|
||||
|
|
|
|||
24
libstdc++-v3/docs/doxygen/doxygroups.cc
Normal file
24
libstdc++-v3/docs/doxygen/doxygroups.cc
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
|
||||
// This just provides documentation for stuff that doesn't need to be in the
|
||||
// source headers themselves. It is a ".cc" file for the sole cheesy reason
|
||||
// that it triggers many different text editors into doing Nice Things when
|
||||
// typing comments. However, it is mentioned nowhere except the *cfg.in files.
|
||||
|
||||
/** @addtogroup SGIextensions
|
||||
*
|
||||
* Because libstdc++-v3 based its implementation of the STL subsections of
|
||||
* the library on the SGI 3.3 implementation, we inherited their extensions
|
||||
* as well.
|
||||
*
|
||||
* They are additionally documented in the
|
||||
* <a href="http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html">
|
||||
* online documentation</a>, a copy of which is also shipped with the
|
||||
* library source code (in .../docs/html/documentation.html). You can also
|
||||
* read the documentation <a href="http://www.sgi.com/tech/stl/">on SGI's
|
||||
* site</a>, which is still running even though the code is not maintained.
|
||||
*
|
||||
* <strong>NB</strong> that the following notes are pulled from various
|
||||
* comments all over the place, so they may seem stilted.
|
||||
* <hr>
|
||||
*/
|
||||
|
||||
|
|
@ -8,7 +8,7 @@
|
|||
<meta NAME="GENERATOR" CONTENT="vi and eight fingers">
|
||||
<title>libstdc++-v3 HOWTO: Chapter 20</title>
|
||||
<link REL=StyleSheet HREF="../lib3styles.css">
|
||||
<!-- $Id: howto.html,v 1.4 2001/05/30 21:55:00 pme Exp $ -->
|
||||
<!-- $Id: howto.html,v 1.5 2001/09/17 23:24:39 pme Exp $ -->
|
||||
</head>
|
||||
<body>
|
||||
|
||||
|
|
@ -171,6 +171,7 @@
|
|||
<code>operator==</code> functions (for types like MyClass) or builtin
|
||||
comparisons (for types like int, char, etc).
|
||||
</p>
|
||||
<a name="pairlt">
|
||||
<p>The less-than operator is a bit odd the first time you see it. It
|
||||
is defined as evaluating to:
|
||||
<PRE>
|
||||
|
|
@ -180,6 +181,7 @@
|
|||
The other operators are not defined using the <code>rel_ops</code>
|
||||
functions above, but their semantics are the same.
|
||||
</p>
|
||||
</a>
|
||||
<p>Finally, there is a template function called <code>make_pair</code>
|
||||
that takes two references-to-const objects and returns an
|
||||
instance of a pair instantiated on their respective types:
|
||||
|
|
@ -200,7 +202,7 @@
|
|||
<P CLASS="fineprint"><em>
|
||||
Comments and suggestions are welcome, and may be sent to
|
||||
<a href="mailto:libstdc++@gcc.gnu.org">the mailing list</a>.
|
||||
<br> $Id: howto.html,v 1.4 2001/05/30 21:55:00 pme Exp $
|
||||
<br> $Id: howto.html,v 1.5 2001/09/17 23:24:39 pme Exp $
|
||||
</em></p>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<meta NAME="GENERATOR" CONTENT="vi and eight fingers">
|
||||
<title>libstdc++-v3 HOWTO: Chapter 23</title>
|
||||
<link REL=StyleSheet HREF="../lib3styles.css">
|
||||
<!-- $Id: howto.html,v 1.8 2001/09/15 00:41:11 pme Exp $ -->
|
||||
<!-- $Id: howto.html,v 1.9 2001/09/17 23:24:39 pme Exp $ -->
|
||||
</head>
|
||||
<body>
|
||||
|
||||
|
|
@ -140,7 +140,8 @@
|
|||
<p><B>A container<bool>. </B> The Committee made provision
|
||||
for the space savings possible with that (N/8) usage previously mentioned,
|
||||
so that you don't have to do wasteful things like
|
||||
<code>Container<char></code> or <code>Container<short int></code>.
|
||||
<code>Container<char></code> or
|
||||
<code>Container<short int></code>.
|
||||
Specifically, <code>vector<bool></code> is required to be
|
||||
specialized for that space savings.
|
||||
</p>
|
||||
|
|
@ -158,12 +159,14 @@
|
|||
<p><B>Extremely weird solutions. </B> If you have access to
|
||||
the compiler and linker at runtime, you can do something insane, like
|
||||
figuring out just how many bits you need, then writing a temporary
|
||||
source code file. That file contains an instantiation of <code>bitset</code>
|
||||
source code file. That file contains an instantiation of
|
||||
<code>bitset</code>
|
||||
for the required number of bits, inside some wrapper functions with
|
||||
unchanging signatures. Have your program then call the
|
||||
compiler on that file using Position Independant Code, then open the
|
||||
newly-created object file and load those wrapper functions. You'll have
|
||||
an instantiation of <code>bitset<N></code> for the exact <code>N</code>
|
||||
an instantiation of <code>bitset<N></code> for the exact
|
||||
<code>N</code>
|
||||
that you need at the time. Don't forget to delete the temporary files.
|
||||
(Yes, this <em>can</em> be, and <em>has been</em>, done.)
|
||||
</p>
|
||||
|
|
@ -178,6 +181,9 @@
|
|||
along the lines of the third category, the author would love to hear
|
||||
from you...
|
||||
</p>
|
||||
<p>Also note that the implementation of bitset used in libstdc++-v3 has
|
||||
<a href="../ext/sgiexts.html#ch23">some extensions</a>.
|
||||
</p>
|
||||
<p>Return <a href="#top">to top of page</a> or
|
||||
<a href="../faq/index.html">to the FAQ</a>.
|
||||
</p>
|
||||
|
|
@ -363,7 +369,7 @@
|
|||
<P CLASS="fineprint"><em>
|
||||
Comments and suggestions are welcome, and may be sent to
|
||||
<a href="mailto:libstdc++@gcc.gnu.org">the mailing list</a>.
|
||||
<br> $Id: howto.html,v 1.8 2001/09/15 00:41:11 pme Exp $
|
||||
<br> $Id: howto.html,v 1.9 2001/09/17 23:24:39 pme Exp $
|
||||
</em></p>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<meta NAME="GENERATOR" CONTENT="vi and eight fingers">
|
||||
<title>libstdc++-v3 HOWTO: Chapter 25</title>
|
||||
<link REL=StyleSheet HREF="../lib3styles.css">
|
||||
<!-- $Id: howto.html,v 1.4 2001/09/15 00:41:11 pme Exp $ -->
|
||||
<!-- $Id: howto.html,v 1.5 2001/09/17 23:24:39 pme Exp $ -->
|
||||
</head>
|
||||
<body>
|
||||
|
||||
|
|
@ -24,7 +24,7 @@
|
|||
<h1>Contents</h1>
|
||||
<ul>
|
||||
<li><a href="#1">Prerequisites</a>
|
||||
<li><a href="#2">Topic</a>
|
||||
<li><a href="#2">Special <code>swap</code>s</a>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
|
@ -71,8 +71,18 @@
|
|||
</p>
|
||||
|
||||
<hr>
|
||||
<h2><a name="2">Topic</a></h2>
|
||||
<p>Blah.
|
||||
<h2><a name="2">Special <code>swap</code>s</a></h2>
|
||||
<p>If you call <code> std::swap(x,y); </code> where x and y are standard
|
||||
containers, then the call will automatically be replaced by a call to
|
||||
<code> x.swap(y); </code> instead.
|
||||
</p>
|
||||
<p>This allows member functions of each container class to take over, and
|
||||
containers' swap functions should have O(1) complexity according to
|
||||
the standard. (And while "should" allows implementations to
|
||||
behave otherwise and remain compliant, this implementation does in
|
||||
fact use constant-time swaps.) This should not be surprising, since
|
||||
for two containers of the same type to swap contents, only some
|
||||
internal pointers to storage need to be exchanged.
|
||||
</p>
|
||||
<p>Return <a href="#top">to top of page</a> or
|
||||
<a href="../faq/index.html">to the FAQ</a>.
|
||||
|
|
@ -87,7 +97,7 @@
|
|||
<P CLASS="fineprint"><em>
|
||||
Comments and suggestions are welcome, and may be sent to
|
||||
<a href="mailto:libstdc++@gcc.gnu.org">the mailing list</a>.
|
||||
<br> $Id: howto.html,v 1.4 2001/09/15 00:41:11 pme Exp $
|
||||
<br> $Id: howto.html,v 1.5 2001/09/17 23:24:39 pme Exp $
|
||||
</em></p>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<meta NAME="GENERATOR" CONTENT="vi and eight fingers">
|
||||
<title>libstdc++-v3 HOWTO: Extensions</title>
|
||||
<link REL=StyleSheet HREF="../lib3styles.css">
|
||||
<!-- $Id: howto.html,v 1.5 2001/05/30 21:55:04 pme Exp $ -->
|
||||
<!-- $Id: howto.html,v 1.6 2001/09/17 23:24:40 pme Exp $ -->
|
||||
</head>
|
||||
<body>
|
||||
|
||||
|
|
@ -37,9 +37,10 @@
|
|||
<h1>Contents</h1>
|
||||
<ul>
|
||||
<li><a href="#1">Ropes and trees and hashes, oh my!</a>
|
||||
<li><a href="#2">Added members</a>
|
||||
<li><a href="#2">Added members and types</a>
|
||||
<li><a href="#3">Allocators</a>
|
||||
<li><a href="#4">Compile-time checks</a>
|
||||
<li><a href="#5">LWG Issues</a>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
|
@ -106,15 +107,19 @@
|
|||
</p>
|
||||
|
||||
<hr>
|
||||
<h2><a name="2">Added members</a></h2>
|
||||
<h2><a name="2">Added members and types</a></h2>
|
||||
<p>Some of the classes in the Standard Library have additional
|
||||
publicly-available members. Of those, some are intended purely for
|
||||
the implementors, for example, additional typedefs. Those won't be
|
||||
described here (or anywhere else). This list will grow slowly, since
|
||||
we expect it to be rare -- most extensions will be self-contained.
|
||||
publicly-available members, and some classes are themselves not in
|
||||
the standard. Of those, some are intended purely for the implementors,
|
||||
for example, additional typedefs. Those won't be described here
|
||||
(or anywhere else).
|
||||
</p>
|
||||
<p>
|
||||
<ul>
|
||||
<li>The extensions added by SGI are so numerous that they have
|
||||
<a href="sgiexts.html">their own page</a>. Since the SGI STL is no
|
||||
longer actively maintained, we will try and keep this code working
|
||||
ourselves.
|
||||
<li><code>filebuf</code>s have another ctor with this signature:<br>
|
||||
<code>basic_filebuf(__c_file_type*, ios_base::openmode, int_type);</code>
|
||||
<br>This comes in very handy in a number of places, such as
|
||||
|
|
@ -157,7 +162,149 @@
|
|||
<a href="../faq/index.html">to the FAQ</a>.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
<h2><a name="5">LWG Issues</a></h2>
|
||||
<p>Everybody's got issues. Even the C++ Standard Library.
|
||||
</p>
|
||||
<p>The Library Working Group, or LWG, is the ISO subcommittee responsible
|
||||
for making changes to the library. They periodically publish an
|
||||
Issues List containing problems and possible solutions. As they reach
|
||||
a consensus on proposed solutions, we often incorporate the solution
|
||||
into libstdc++-v3.
|
||||
</p>
|
||||
<p>Here are the issues which have resulted in code changes to the library.
|
||||
The links are to the specific defect reports from a <strong>partial
|
||||
copy </strong> of the
|
||||
Issues List. You can read the full version online at the ISO C++
|
||||
Committee homepage, linked to on the GCC "Readings" page. If
|
||||
you spend a lot of time reading the issues, we recommend downloading
|
||||
the ZIP file and reading them locally.
|
||||
</p>
|
||||
<p>(NB: <strong>partial copy</strong> means that not all links within
|
||||
the lwg-*.html pages will work.
|
||||
Specifically, links to defect reports that have not been accorded full
|
||||
DR status will probably break. Rather than trying to mirror the
|
||||
entire issues list on our overworked web server, we recommend you go
|
||||
to the LWG homepage instead.)
|
||||
</p>
|
||||
<p>
|
||||
If a DR is not listed here, we may simply not have gotten to it yet;
|
||||
feel free to submit a patch. Search the include/bits and src
|
||||
directories for appearances of _GLIBCPP_RESOLVE_LIB_DEFECTS for
|
||||
examples of style. Note that we usually do not make changes to the code
|
||||
until an issue has reached <a href="lwg-active.html#DR">DR</a> status.
|
||||
</p>
|
||||
<p><dl>
|
||||
<!-- FIXME: locale_facets.h/tcc has a fix for get/num_get which I can't ID. -->
|
||||
|
||||
<dt><a href="lwg-defects.html#5">5</a>:
|
||||
<em>string::compare specification questionable</em>
|
||||
<dd>This should be two overloaded functions rather than a single function.
|
||||
|
||||
<dt><a href="lwg-defects.html#17">17</a>:
|
||||
<em>Bad bool parsing</em>
|
||||
<dd>Apparently extracting Boolean values was messed up...
|
||||
|
||||
<dt><a href="lwg-defects.html#25">25</a>:
|
||||
<em>String operator<< uses width() value wrong</em>
|
||||
<dd>Padding issues.
|
||||
|
||||
<dt><a href="lwg-defects.html#48">48</a>:
|
||||
<em>Use of non-existent exception constructor</em>
|
||||
<dd>An instance of <code>ios_base::failure</code> is constructed instead.
|
||||
|
||||
<dt><a href="lwg-defects.html#49">49</a>:
|
||||
<em>Underspecification of ios_base::sync_with_stdio</em>
|
||||
<dd>The return type is the <em>previous</em> state of synchronization.
|
||||
|
||||
<dt><a href="lwg-defects.html#50">50</a>:
|
||||
<em>Copy constructor and assignment operator of ios_base</em>
|
||||
<dd>These members functions are declared <code>private</code> and are
|
||||
thus inaccessible. Specifying the correct semantics of
|
||||
"copying stream state" was deemed too complicated.
|
||||
|
||||
<dt><a href="lwg-defects.html#68">68</a>:
|
||||
<em>Extractors for char* should store null at end</em>
|
||||
<dd>And they do now. An editing glitch in the last item in the list of
|
||||
[27.6.1.2.3]/7.
|
||||
|
||||
<dt><a href="lwg-defects.html#74">74</a>:
|
||||
<em>Garbled text for codecvt::do_max_length</em>
|
||||
<dd>The text of the standard was gibberish. Typos gone rampant.
|
||||
|
||||
<dt><a href="lwg-defects.html#83">83</a>:
|
||||
<em>string::npos vs. string::max_size()</em>
|
||||
<dd>Safety checks on the size of the string should test against
|
||||
<code>max_size()</code> rather than <code>npos</code>.
|
||||
|
||||
<dt><a href="lwg-defects.html#109">109</a>:
|
||||
<em>Missing binders for non-const sequence elements</em>
|
||||
<dd>The <code>binder1st</code> and <code>binder2nd</code> didn't have an
|
||||
<code>operator()</code> taking a non-const parameter.
|
||||
|
||||
<dt><a href="lwg-defects.html#110">110</a>:
|
||||
<em>istreambuf_iterator::equal not const</em>
|
||||
<dd>This was not a const member function. Note that the DR says to
|
||||
replace the function with a const one; we have instead provided an
|
||||
overloaded version with identical contents.
|
||||
|
||||
<dt><a href="lwg-defects.html#129">129</a>:
|
||||
<em>Need error indication from seekp() and seekg()</em>
|
||||
<dd>These functions set <code>failbit</code> on error now.
|
||||
|
||||
<dt><a href="lwg-defects.html#136">136</a>:
|
||||
<em>seekp, seekg setting wrong streams?</em>
|
||||
<dd><code>seekp</code> should only set the output stream, and
|
||||
<code>seekg</code> should only set the input stream.
|
||||
|
||||
<!--<dt><a href="lwg-defects.html#159">159</a>:
|
||||
<em>Strange use of underflow()</em>
|
||||
<dd>In fstream.tcc, the basic_filebuf<>::showmanyc() function
|
||||
should probably not be calling <code>underflow()</code>.-->
|
||||
|
||||
<dt><a href="lwg-active.html#167">167</a>:
|
||||
<em>Improper use of traits_type::length()</em>
|
||||
<dd><code>op<<</code> with a <code>const char*</code> was
|
||||
calculating an incorrect number of characters to write.
|
||||
|
||||
<dt><a href="lwg-defects.html#181">181</a>:
|
||||
<em>make_pair() unintended behavior</em>
|
||||
<dd>This function used to take its arguments as reference-to-const, now
|
||||
it copies them (pass by value).
|
||||
|
||||
<dt><a href="lwg-defects.html#195">195</a>:
|
||||
<em>Should basic_istream::sentry's constructor ever set eofbit?</em>
|
||||
<dd>Yes, it can, specifically if EOF is reached while skipping whitespace.
|
||||
|
||||
<dt><a href="lwg-defects.html#211">211</a>:
|
||||
<em>operator>>(istream&, string&) doesn't set failbit</em>
|
||||
<dd>If nothing is extracted into the string, <code>op>></code> now
|
||||
sets <code>failbit</code> (which can cause an exception, etc, etc).
|
||||
|
||||
<dt><a href="lwg-defects.html#214">214</a>:
|
||||
<em>set::find() missing const overload</em>
|
||||
<dd>Both <code>set</code> and <code>multiset</code> were missing
|
||||
overloaded find, lower_bound, upper_bound, and equal_range functions
|
||||
for const instances.
|
||||
|
||||
<dt><a href="lwg-defects.html#251">251</a>:
|
||||
<em>basic_stringbuf missing allocator_type</em>
|
||||
<dd>This nested typdef was originally not specified.
|
||||
|
||||
<dt><a href="lwg-defects.html#265">265</a>:
|
||||
<em>std::pair::pair() effects overly restrictive</em>
|
||||
<dd>The default ctor would build its members from copies of temporaries;
|
||||
now it simply uses their respective default ctors.
|
||||
|
||||
<!--
|
||||
<dt><a href="lwg-defects.html#"></a>:
|
||||
<em></em>
|
||||
<dd>
|
||||
|
||||
-->
|
||||
</dl></p>
|
||||
<p>Return <a href="#top">to top of page</a> or
|
||||
<a href="../faq/index.html">to the FAQ</a>.
|
||||
|
||||
|
||||
<!-- ####################################################### -->
|
||||
|
|
@ -166,7 +313,7 @@
|
|||
<P CLASS="fineprint"><em>
|
||||
Comments and suggestions are welcome, and may be sent to
|
||||
<a href="mailto:libstdc++@gcc.gnu.org">the mailing list</a>.
|
||||
<br> $Id: howto.html,v 1.5 2001/05/30 21:55:04 pme Exp $
|
||||
<br> $Id: howto.html,v 1.6 2001/09/17 23:24:40 pme Exp $
|
||||
</em></p>
|
||||
|
||||
|
||||
|
|
|
|||
6442
libstdc++-v3/docs/html/ext/lwg-active.html
Normal file
6442
libstdc++-v3/docs/html/ext/lwg-active.html
Normal file
File diff suppressed because it is too large
Load diff
4866
libstdc++-v3/docs/html/ext/lwg-defects.html
Normal file
4866
libstdc++-v3/docs/html/ext/lwg-defects.html
Normal file
File diff suppressed because it is too large
Load diff
233
libstdc++-v3/docs/html/ext/sgiexts.html
Normal file
233
libstdc++-v3/docs/html/ext/sgiexts.html
Normal file
|
|
@ -0,0 +1,233 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta NAME="AUTHOR" CONTENT="pme@gcc.gnu.org (Phil Edwards)">
|
||||
<meta NAME="KEYWORDS" CONTENT="libstdc++, libstdc++-v3, GCC, g++, STL, SGI">
|
||||
<meta NAME="DESCRIPTION" CONTENT="SGI extensions preserved in libstdc++-v3.">
|
||||
<meta NAME="GENERATOR" CONTENT="vi and eight fingers">
|
||||
<title>SGI extensions to the library in libstdc++-v3</title>
|
||||
<link REL=StyleSheet HREF="lib3styles.css">
|
||||
<!-- $Id: explanations.html,v 1.2 2001/09/17 23:24:38 pme Exp $ -->
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<h1 CLASS="centered"><a name="top">SGI extensions to the library in
|
||||
libstdc++-v3</a></h1>
|
||||
|
||||
<p>This page describes the extensions that SGI made to their version of the
|
||||
STL subset of the Standard C++ Library. For a time we
|
||||
<a href="../faq/index.html#5_3">tracked and imported changes and updates
|
||||
from most of the SGI STL</a>, up through their (apparently) final release.
|
||||
Their extensions were mostly preserved.
|
||||
</p>
|
||||
|
||||
<p>They are listed according to the chapters of the library that they
|
||||
extend (see <a href="../documentation.html#3">the chapter-specific notes</a>
|
||||
for a description). Not every chapter may have extensions, and the
|
||||
extensions may come and go. Also, this page is incomplete because the
|
||||
author is pressed for time. Check back often; the latest change was on
|
||||
$Date$ (UTC).
|
||||
</p>
|
||||
|
||||
<p>Descriptions range from the scanty to the verbose. You should also check
|
||||
the <a href="../documentation.html#4">generated documentation</a> for notes
|
||||
and comments, especially for entries marked with '*'. For more complete
|
||||
doumentation, see the SGI website. For <em>really</em> complete
|
||||
documentation, buy a copy of Matt Austern's book. *grin*
|
||||
</p>
|
||||
|
||||
<p>Back to the <a href="howto.html">libstdc++-v3 extensions</a>.
|
||||
|
||||
|
||||
<!-- ####################################################### -->
|
||||
<hr>
|
||||
<a name="ch20"><h3>Chapter 20</h3></a>
|
||||
<p>The <functional> header contains many additional functors and
|
||||
helper functions, extending section 20.3. They are implemented in the
|
||||
file stl_function.h:
|
||||
<ul>
|
||||
<li><code>identity_element</code> for addition and multiplication. *
|
||||
<li>The functor <code>identity</code>, whose op() returns the argument
|
||||
unchanged. *
|
||||
<li>Composition functors <code>unary_function</code> and
|
||||
<code>binary_function</code>, and their helpers <code>compose1</code>
|
||||
and <code>compose2</code>. *
|
||||
<li><code>select1st</code> and <code>select2nd</code>, to strip pairs. *
|
||||
<li><code>project1st</code> and <code>project2nd</code>. *
|
||||
<li>A set of functors/functions which always return the same result. They
|
||||
are <code>constant_void_fun, constant_binary_fun, constant_unary_fun,
|
||||
constant0, constant1, and constant2. *
|
||||
<li>The class <code>subtractive_rng</code>. *
|
||||
<li>mem_fun adaptor helpers mem_fun1 and mem_fun1_ref are provided for
|
||||
backwards compatibility.
|
||||
</ul></p>
|
||||
<p>20.4.3 is extended with a special version of
|
||||
<code>get_temporary_buffer</code> taking a second argument. The argument
|
||||
is a pointer, which is ignored, but can be used to specify the template
|
||||
type (instead of using explicit function template arguments like the
|
||||
standard version does). That is, in addition to
|
||||
<pre>
|
||||
get_temporary_buffer<int>(5);</pre>
|
||||
you can also use
|
||||
<pre>
|
||||
get_temporary_buffer(5, (int*)0);</pre>
|
||||
</p>
|
||||
<p>A class <code>temporary_buffer</code> is given in stl_tempbuf.h. *
|
||||
</p>
|
||||
<p>The specialized algorithms of section 20.4.4 are extended with
|
||||
<code>uninitialized_copy_n</code>. *
|
||||
</p>
|
||||
<p>Return <a href="howto.html">to the main extensions page</a> or
|
||||
<a href="http://gcc.gnu.org/libstdc++/">to the homepage</a>.
|
||||
</p>
|
||||
|
||||
|
||||
<hr>
|
||||
<a name="ch23"><h3>Chapter 23</h3></a>
|
||||
<p>A few extensions and nods to backwards-compatability have been made with
|
||||
containers. Those dealing with older SGI-style allocators are dealt with
|
||||
elsewhere. The remaining ones all deal with bits:
|
||||
</p>
|
||||
<p>The old pre-standard <code>bit_vector</code> class is present for
|
||||
backwards compatibility. It is simply a typedef for the
|
||||
<code>vector<bool></code> specialization.
|
||||
</p>
|
||||
<p>The <code>bitset</code> class has a number of extensions, described in the
|
||||
rest of this item. First, we'll mention that this implementation of
|
||||
<code>bitset<N></code> is specialized for cases where N number of
|
||||
bits will fit into a single word of storage. If your choice of N is
|
||||
within that range (<=32 on i686-pc-linux-gnu, for example), then all
|
||||
of the operations will be faster.
|
||||
</p>
|
||||
<p>There are
|
||||
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
|
||||
of "bitset<N>," then their names and signatures are:
|
||||
<pre>
|
||||
bitset<N>& _Unchecked_set (size_t pos);
|
||||
bitset<N>& _Unchecked_set (size_t pos, int val);
|
||||
bitset<N>& _Unchecked_reset (size_t pos);
|
||||
bitset<N>& _Unchecked_flip (size_t pos);
|
||||
bool _Unchecked_test (size_t pos);</pre>
|
||||
Note that these may in fact be removed in the future, although we have
|
||||
no present plans to do so (and there doesn't seem to be any immediate
|
||||
reason to).
|
||||
</p>
|
||||
<p>
|
||||
The semantics of member function <code>operator[]</code> are not specified
|
||||
in the C++ standard. A long-standing defect report calls for sensible
|
||||
obvious semantics, which are already implemented here: <code>op[]</code>
|
||||
on a const bitset returns a bool, and for a non-const bitset returns a
|
||||
<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...
|
||||
</p>
|
||||
<p>Finally, two additional searching functions have been added. They return
|
||||
the index of the first "on" bit, and the index of the first
|
||||
"on" bit that is after <code>prev</code>, respectively:
|
||||
<pre>
|
||||
size_t _Find_first() const;
|
||||
size_t _Find_next (size_t prev) const;</pre>
|
||||
The same caveat given for the _Unchecked_* functions applies here also.
|
||||
</p>
|
||||
<p>Return <a href="howto.html">to the main extensions page</a> or
|
||||
<a href="http://gcc.gnu.org/libstdc++/">to the homepage</a>.
|
||||
</p>
|
||||
|
||||
|
||||
<hr>
|
||||
<a name="ch24"><h3>Chapter 24</h3></a>
|
||||
<p>24.3.2 describes <code>struct iterator</code>, which didn't exist in the
|
||||
original HP STL implementation (the language wasn't rich enough at the
|
||||
time). For backwards compatibility, base classes are provided which
|
||||
declare the same nested typedefs:
|
||||
<ul>
|
||||
<li>input_iterator
|
||||
<li>output_iterator
|
||||
<li>forward_iterator
|
||||
<li>bidirectional_iterator
|
||||
<li>random_access_iterator
|
||||
</ul>
|
||||
</p>
|
||||
<p>24.3.4 describes iterator operation <code>distance</code>, which takes
|
||||
two iterators and returns a result. It is extended by another signature
|
||||
which takes two iterators and a reference to a result. The result is
|
||||
modified, and the function returns nothing.
|
||||
</p>
|
||||
<p>Return <a href="howto.html">to the main extensions page</a> or
|
||||
<a href="http://gcc.gnu.org/libstdc++/">to the homepage</a>.
|
||||
</p>
|
||||
|
||||
|
||||
<hr>
|
||||
<a name="ch25"><h3>Chapter 25</h3></a>
|
||||
<p>25.1.6 (count, count_if) is extended with two more versions of count
|
||||
and count_if. The standard versions return their results. The
|
||||
additional signatures return void, but take a final parameter by
|
||||
reference to which they assign their results, e.g.,
|
||||
<pre>
|
||||
void count (first, last, value, n);</pre>
|
||||
</p>
|
||||
<p>25.2 (mutating algorithms) is extended with two families of signatures,
|
||||
random_sample and random_sample_n.
|
||||
</p>
|
||||
<p>25.2.1 (copy) is extended with
|
||||
<pre>
|
||||
copy_n (_InputIter first, _Size count, _OutputIter result);</pre>
|
||||
which copies the first 'count' elements at 'first' into 'result'.
|
||||
</p>
|
||||
<p>25.3 (sorting 'n' heaps 'n' stuff) is extended with some helper
|
||||
predicates. Look in the doxygen-generated pages for notes on these.
|
||||
<ul>
|
||||
<li><code>is_heap</code> tests whether or not a range is a heap.
|
||||
<li><code>is_sorted</code> tests whether or not a range is sorted in
|
||||
nondescending order.
|
||||
</ul>
|
||||
</p>
|
||||
<p>25.3.8 (lexigraphical_compare) is extended with
|
||||
<pre>
|
||||
lexicographical_compare_3way(_InputIter1 first1, _InputIter1 last1,
|
||||
_InputIter2 first2, _InputIter2 last2)</pre>
|
||||
which does... what?
|
||||
</p>
|
||||
<p>Return <a href="howto.html">to the main extensions page</a> or
|
||||
<a href="http://gcc.gnu.org/libstdc++/">to the homepage</a>.
|
||||
</p>
|
||||
|
||||
|
||||
<hr>
|
||||
<a name="ch26"><h3>Chapter 26</h3></a>
|
||||
<p>26.4, the generalized numeric operations such as accumulate, are extended
|
||||
with the following functions:
|
||||
<pre>
|
||||
power (x, n);
|
||||
power (x, n, moniod_operation);</pre>
|
||||
Returns, in FORTRAN syntax, "x ** n" where n>=0. In the
|
||||
case of n == 0, returns the <a href="#ch20">identity element</a> for the
|
||||
monoid operation. The two-argument signature uses multiplication (for
|
||||
a true "power" implementation), but addition is supported as well.
|
||||
The operation functor must be associative.
|
||||
</p>
|
||||
<p>The <code>iota</code> function wins the award for Extension With the
|
||||
Coolest Name. It "assigns sequentially increasing values to a range.
|
||||
That is, it assigns value to *first, value + 1 to *(first + 1) and so
|
||||
on." Quoted from SGI documentation.
|
||||
<pre>
|
||||
void iota(_ForwardIter first, _ForwardIter last, _Tp value);</pre>
|
||||
</p>
|
||||
<p>Return <a href="howto.html">to the main extensions page</a> or
|
||||
<a href="http://gcc.gnu.org/libstdc++/">to the homepage</a>.
|
||||
</p>
|
||||
|
||||
|
||||
<!-- ####################################################### -->
|
||||
|
||||
<hr>
|
||||
<P CLASS="fineprint"><em>
|
||||
$Id: explanations.html,v 1.2 2001/09/17 23:24:38 pme Exp $
|
||||
</em></p>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -9,7 +9,7 @@
|
|||
** Locations of "the most recent snapshot is the Nth" text are
|
||||
** answers 1_1, 1_4, 4_1, 5_6.
|
||||
-->
|
||||
<!-- $Id: index.html,v 1.10 2001/07/18 21:37:06 pme Exp $ -->
|
||||
<!-- $Id: index.html,v 1.11 2001/09/17 23:24:40 pme Exp $ -->
|
||||
</head>
|
||||
<body>
|
||||
|
||||
|
|
@ -368,6 +368,25 @@ which is no longer available, thanks deja...-->
|
|||
the mailing list or look through recent archives. The RELEASE-
|
||||
NOTES and BUGS files are generally kept up-to-date.</em>
|
||||
|
||||
<p>For 3.0.1, the most common "bug" is an apparently missing
|
||||
"<code>../</code>" in include/Makefile, resulting in files
|
||||
like gthr.h and gthr-single.h not being found.
|
||||
</p>
|
||||
<p>Please read
|
||||
<a href="http://gcc.gnu.org/install/configure.html">the configuration
|
||||
instructions for GCC</a>,
|
||||
specifically the part about configuring in a seperate build directory,
|
||||
and how strongly recommended it is. Building in the source directory
|
||||
is fragile, is rarely tested, and tends to break, as in this case.
|
||||
Work has already gone into the source tree to make this less painful
|
||||
for the next release.
|
||||
</p>
|
||||
<p><strong>Please do not report this as a bug. We know about it.</strong>
|
||||
Reporting this -- or any other problem that's already been fixed --
|
||||
hinders the development of GCC, because we have to take time to
|
||||
respond to your report. Thank you.
|
||||
</p>
|
||||
|
||||
<h2><a name="4_1">4.1 What works already?</a></h2>
|
||||
<p>This is a verbatim clip from the "Status" section
|
||||
of the RELEASE-NOTES for the latest snapshot.
|
||||
|
|
@ -572,7 +591,8 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
|||
libstdc++. Some of that is already happening, see 4.2. Some of
|
||||
those changes are being predicted by the library maintainers, and
|
||||
we add code to the library based on what the current proposed
|
||||
resolution specifies.
|
||||
resolution specifies. Those additions are listed in
|
||||
<a href="../ext/howto.html#5">the extensions page</a>.
|
||||
</p>
|
||||
<li><p>Performance tuning. Lots of performance tuning. This too is
|
||||
already underway for post-3.0 releases, starting with memory
|
||||
|
|
@ -678,7 +698,7 @@ HREF="http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html">speculation</a>.
|
|||
<P CLASS="fineprint"><em>
|
||||
Comments and suggestions are welcome, and may be sent to
|
||||
<a href="mailto:libstdc++@gcc.gnu.org">the mailing list</a>.
|
||||
<br> $Id: index.html,v 1.10 2001/07/18 21:37:06 pme Exp $
|
||||
<br> $Id: index.html,v 1.11 2001/09/17 23:24:40 pme Exp $
|
||||
</em></p>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -286,6 +286,22 @@
|
|||
mailing list or look through recent archives. The RELEASE- NOTES and
|
||||
BUGS files are generally kept up-to-date.
|
||||
|
||||
For 3.0.1, the most common "bug" is an apparently missing "../" in
|
||||
include/Makefile, resulting in files like gthr.h and gthr-single.h not
|
||||
being found.
|
||||
|
||||
Please read [58]the configuration instructions for GCC, specifically
|
||||
the part about configuring in a seperate build directory, and how
|
||||
strongly recommended it is. Building in the source directory is
|
||||
fragile, is rarely tested, and tends to break, as in this case. Work
|
||||
has already gone into the source tree to make this less painful for
|
||||
the next release.
|
||||
|
||||
Please do not report this as a bug. We know about it. Reporting this
|
||||
-- or any other problem that's already been fixed -- hinders the
|
||||
development of GCC, because we have to take time to respond to your
|
||||
report. Thank you.
|
||||
|
||||
4.1 What works already?
|
||||
|
||||
This is a verbatim clip from the "Status" section of the RELEASE-NOTES
|
||||
|
|
@ -327,16 +343,16 @@ New:
|
|||
|
||||
4.3 Bugs in the C++ language/lib specification
|
||||
|
||||
Yes, unfortunately, there are some. In a [58]message to the list,
|
||||
Yes, unfortunately, there are some. In a [59]message to the list,
|
||||
Nathan Myers announced that he has started a list of problems in the
|
||||
ISO C++ Standard itself, especially with regard to the chapters that
|
||||
concern the library. The list itself is [59]posted on his website.
|
||||
concern the library. The list itself is [60]posted on his website.
|
||||
Developers who are having problems interpreting the Standard may wish
|
||||
to consult his notes.
|
||||
|
||||
For those people who are not part of the ISO Library Group (i.e.,
|
||||
nearly all of us needing to read this page in the first place :-), a
|
||||
public list of the library defects is occasionally published [60]here.
|
||||
public list of the library defects is occasionally published [61]here.
|
||||
_________________________________________________________________
|
||||
|
||||
4.4 Things in libstdc++ that look like bugs
|
||||
|
|
@ -357,14 +373,14 @@ New:
|
|||
same namespace as other comparison functions (e.g., 'using' them and
|
||||
the <iterator> header), then you will suddenly be faced with huge
|
||||
numbers of ambiguity errors. This was discussed on the -v3 list;
|
||||
Nathan Myers [61]sums things up here.
|
||||
Nathan Myers [62]sums things up here.
|
||||
|
||||
The g++-3 headers are not ours
|
||||
|
||||
If you have found an extremely broken header file which is causing
|
||||
problems for you, look carefully before submitting a "high" priority
|
||||
bug report (which you probably shouldn't do anyhow; see the last
|
||||
paragraph of the page describing [62]the GCC bug database).
|
||||
paragraph of the page describing [63]the GCC bug database).
|
||||
|
||||
If the headers are in ${prefix}/include/g++-3, then you are using the
|
||||
old libstdc++-v2 library, which is nonstandard and unmaintained. Do
|
||||
|
|
@ -372,7 +388,7 @@ New:
|
|||
|
||||
Currently our header files are installed in ${prefix}/include/g++-v3
|
||||
(see the 'v'?). This may change with the next release of GCC, as it
|
||||
may be too confusing, but [63]the question has not yet been decided.
|
||||
may be too confusing, but [64]the question has not yet been decided.
|
||||
|
||||
glibc If you're on a GNU/Linux system and have just upgraded to glibc
|
||||
2.2, but are still using gcc 2.95.2, then you should have read the
|
||||
|
|
@ -385,7 +401,7 @@ type has changed in glibc 2.2. The patch is at
|
|||
http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
||||
|
||||
|
||||
Note that 2.95.x shipped with the [64]old v2 library which is no
|
||||
Note that 2.95.x shipped with the [65]old v2 library which is no
|
||||
longer maintained. Also note that gcc 2.95.3 fixes this problem, but
|
||||
requires a separate patch for libstdc++-v3.
|
||||
|
||||
|
|
@ -398,23 +414,23 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
|||
visibility, or you just plain forgot, etc).
|
||||
|
||||
More information, including how to optionally enable/disable the
|
||||
checks, is available [65]here.
|
||||
checks, is available [66]here.
|
||||
_________________________________________________________________
|
||||
|
||||
4.5 Aw, that's easy to fix!
|
||||
|
||||
If you have found a bug in the library and you think you have a
|
||||
working fix, then send it in! The main GCC site has a page on
|
||||
[66]submitting patches that covers the procedure, but for libstdc++
|
||||
[67]submitting patches that covers the procedure, but for libstdc++
|
||||
you should also send the patch to our mailing list in addition to the
|
||||
GCC patches mailing list. The libstdc++ [67]contributors' page also
|
||||
GCC patches mailing list. The libstdc++ [68]contributors' page also
|
||||
talks about how to submit patches.
|
||||
|
||||
In addition to the description, the patch, and the ChangeLog entry, it
|
||||
is a Good Thing if you can additionally create a small test program to
|
||||
test for the presence of the bug that your patch fixes. Bugs have a
|
||||
way of being reintroduced; if an old bug creeps back in, it will be
|
||||
caught immediately by the [68]testsuite -- but only if such a test
|
||||
caught immediately by the [69]testsuite -- but only if such a test
|
||||
exists.
|
||||
_________________________________________________________________
|
||||
|
||||
|
|
@ -448,7 +464,8 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
|||
libstdc++. Some of that is already happening, see 4.2. Some of
|
||||
those changes are being predicted by the library maintainers, and
|
||||
we add code to the library based on what the current proposed
|
||||
resolution specifies.
|
||||
resolution specifies. Those additions are listed in [70]the
|
||||
extensions page.
|
||||
2. Performance tuning. Lots of performance tuning. This too is
|
||||
already underway for post-3.0 releases, starting with memory
|
||||
expansion in container classes and buffer usage in synchronized
|
||||
|
|
@ -463,13 +480,13 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
|||
type from C99.) Bugfixes and rewrites (to improve or fix thread
|
||||
safety, for instance) will of course be a continuing task.
|
||||
|
||||
[69]This question about the next libstdc++ prompted some brief but
|
||||
interesting [70]speculation.
|
||||
[71]This question about the next libstdc++ prompted some brief but
|
||||
interesting [72]speculation.
|
||||
_________________________________________________________________
|
||||
|
||||
5.3 What about the STL from SGI?
|
||||
|
||||
The [71]STL from SGI, version 3.3, was the most recent merge of the
|
||||
The [73]STL from SGI, version 3.3, was the most recent merge of the
|
||||
STL codebase. The code in libstdc++ contains many fixes and changes,
|
||||
and it is very likely that the SGI code is no longer under active
|
||||
development. We expect that no future merges will take place.
|
||||
|
|
@ -490,7 +507,7 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
|||
#include <ext/hash_map>
|
||||
|
||||
|
||||
Extensions to the library have [72]their own page.
|
||||
Extensions to the library have [74]their own page.
|
||||
_________________________________________________________________
|
||||
|
||||
5.5 [removed]
|
||||
|
|
@ -506,8 +523,8 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
|||
|
||||
This is assuming that your idea of "multithreaded" is the same as
|
||||
ours... The general question of multithreading and libstdc++-v3 is
|
||||
addressed in the chapter-specific advice for [73]Library Introduction.
|
||||
Threadsafe containers are covered in more detail in [74]the Received
|
||||
addressed in the chapter-specific advice for [75]Library Introduction.
|
||||
Threadsafe containers are covered in more detail in [76]the Received
|
||||
Wisdom section on containers.
|
||||
_________________________________________________________________
|
||||
|
||||
|
|
@ -519,17 +536,17 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
|||
their two-meeting commitment for voting rights, may get a copy of the
|
||||
standard from their respective national standards organization. In the
|
||||
USA, this national standards organization is ANSI and their website is
|
||||
right [75]here. (And if you've already registered with them, clicking
|
||||
this link will take you to directly to the place where you can [76]buy
|
||||
right [77]here. (And if you've already registered with them, clicking
|
||||
this link will take you to directly to the place where you can [78]buy
|
||||
the standard on-line.
|
||||
|
||||
Who is your country's member body? Visit the [77]ISO homepage and find
|
||||
Who is your country's member body? Visit the [79]ISO homepage and find
|
||||
out!
|
||||
_________________________________________________________________
|
||||
|
||||
Comments and suggestions are welcome, and may be sent to [78]the
|
||||
Comments and suggestions are welcome, and may be sent to [80]the
|
||||
mailing list.
|
||||
$Id: index.html,v 1.10 2001/07/18 21:37:06 pme Exp $
|
||||
$Id: index.html,v 1.11 2001/09/17 23:24:40 pme Exp $
|
||||
|
||||
References
|
||||
|
||||
|
|
@ -590,24 +607,26 @@ References
|
|||
55. http://www.gnu.org/software/cvs/cvs.html
|
||||
56. http://www.cvshome.org/
|
||||
57. http://gcc.gnu.org/ml/libstdc++/2000-12/msg00279.html
|
||||
58. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html
|
||||
59. http://www.cantrip.org/draft-bugs.txt
|
||||
60. http://anubis.dkuug.dk/jtc1/sc22/wg21/
|
||||
61. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html
|
||||
62. http://gcc.gnu.org/gnatswrite.html
|
||||
63. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html
|
||||
64. ../faq/index.html#4_4_interface
|
||||
65. ../19_diagnostics/howto.html#3
|
||||
66. http://gcc.gnu.org/contribute.html
|
||||
67. ../17_intro/contribute.html
|
||||
68. ../faq/index.html#2_4
|
||||
69. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html
|
||||
70. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html
|
||||
71. http://www.sgi.com/Technology/STL/
|
||||
72. ../ext/howto.html
|
||||
73. http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/howto.html#3
|
||||
74. http://gcc.gnu.org/onlinedocs/libstdc++/23_containers/howto.html
|
||||
75. http://www.ansi.org/
|
||||
76. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
|
||||
77. http://www.iso.ch/
|
||||
78. mailto:libstdc++@gcc.gnu.org
|
||||
58. http://gcc.gnu.org/install/configure.html
|
||||
59. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html
|
||||
60. http://www.cantrip.org/draft-bugs.txt
|
||||
61. http://anubis.dkuug.dk/jtc1/sc22/wg21/
|
||||
62. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html
|
||||
63. http://gcc.gnu.org/gnatswrite.html
|
||||
64. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html
|
||||
65. ../faq/index.html#4_4_interface
|
||||
66. ../19_diagnostics/howto.html#3
|
||||
67. http://gcc.gnu.org/contribute.html
|
||||
68. ../17_intro/contribute.html
|
||||
69. ../faq/index.html#2_4
|
||||
70. ../ext/howto.html#5
|
||||
71. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html
|
||||
72. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html
|
||||
73. http://www.sgi.com/Technology/STL/
|
||||
74. ../ext/howto.html
|
||||
75. http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/howto.html#3
|
||||
76. http://gcc.gnu.org/onlinedocs/libstdc++/23_containers/howto.html
|
||||
77. http://www.ansi.org/
|
||||
78. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
|
||||
79. http://www.iso.ch/
|
||||
80. mailto:libstdc++@gcc.gnu.org
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ namespace std
|
|||
{
|
||||
public:
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
// Can't do exception(_msg) as defined in 27.4.2.1.1
|
||||
//48. Use of non-existent exception constructor
|
||||
explicit
|
||||
failure(const string& __str) throw();
|
||||
|
||||
|
|
@ -397,6 +397,7 @@ namespace std
|
|||
ios_base();
|
||||
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
//50. Copy constructor and assignment operator of ios_base
|
||||
private:
|
||||
ios_base(const ios_base&);
|
||||
|
||||
|
|
|
|||
|
|
@ -1176,7 +1176,7 @@ namespace std
|
|||
__in.width(0);
|
||||
}
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
// 2000-02-01 Number to be determined
|
||||
//211. operator>>(istream&, string&) doesn't set failbit
|
||||
if (!__extracted)
|
||||
__in.setstate (ios_base::failbit);
|
||||
#endif
|
||||
|
|
|
|||
|
|
@ -580,6 +580,7 @@ namespace std
|
|||
{ return do_get(__in, __end, __io, __err, __v); }
|
||||
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
//XXX. What number?
|
||||
iter_type
|
||||
get(iter_type __in, iter_type __end, ios_base& __io,
|
||||
ios_base::iostate& __err, short& __v) const
|
||||
|
|
@ -661,6 +662,7 @@ namespace std
|
|||
do_get(iter_type, iter_type, ios_base&, ios_base::iostate&, bool&) const;
|
||||
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
//XXX. What number?
|
||||
virtual iter_type
|
||||
do_get(iter_type, iter_type, ios_base&, ios_base::iostate&, short&) const;
|
||||
virtual iter_type
|
||||
|
|
|
|||
|
|
@ -663,6 +663,7 @@ namespace std
|
|||
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
// NB: This is an unresolved library defect #17
|
||||
//17. Bad bool parsing
|
||||
template<typename _CharT, typename _InIter>
|
||||
_InIter
|
||||
num_get<_CharT, _InIter>::
|
||||
|
|
@ -734,6 +735,7 @@ namespace std
|
|||
#endif
|
||||
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
//XXX. Which number? Presumably same as in locale_facets.h...
|
||||
template<typename _CharT, typename _InIter>
|
||||
_InIter
|
||||
num_get<_CharT, _InIter>::
|
||||
|
|
|
|||
|
|
@ -644,6 +644,7 @@ namespace std
|
|||
typedef basic_ostream<_CharT, _Traits> __ostream_type;
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
// 167. Improper use of traits_type::length()
|
||||
// Note that this is only in 'Review' status.
|
||||
typedef char_traits<char> __ctraits_type;
|
||||
#endif
|
||||
typename __ostream_type::sentry __cerb(__out);
|
||||
|
|
|
|||
|
|
@ -55,11 +55,6 @@
|
|||
// individual bits. This allows us to specialize _Base_bitset for the
|
||||
// important special case where the bitset is only a single word.
|
||||
|
||||
// The C++ standard does not define the precise semantics of operator[].
|
||||
// In this implementation the const version of operator[] is equivalent
|
||||
// to test(), except that it does no range checking. The non-const version
|
||||
// returns a reference to a bit, again without doing any range checking.
|
||||
|
||||
|
||||
#include <bits/std_cstddef.h> // for size_t
|
||||
#include <bits/std_cstring.h> // for memset
|
||||
|
|
@ -618,6 +613,9 @@ public:
|
|||
|
||||
// element access:
|
||||
//for b[i];
|
||||
// _GLIBCPP_RESOLVE_LIB_DEFECTS Note that this implementation already
|
||||
// resolves DR 11 (items 1 and 2), but does not do the range-checking
|
||||
// required by that DR's resolution. -pme
|
||||
reference operator[](size_t __pos) { return reference(*this,__pos); }
|
||||
bool operator[](size_t __pos) const { return _Unchecked_test(__pos); }
|
||||
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ namespace std
|
|||
class ostreambuf_iterator;
|
||||
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
// Not included.
|
||||
// Not included. (??? Apparently no LWG number?)
|
||||
class ios_base;
|
||||
#endif
|
||||
|
||||
|
|
|
|||
|
|
@ -202,7 +202,7 @@ namespace std
|
|||
|
||||
private:
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
// Not defined.
|
||||
// Not defined. (Side effect of DR 50.)
|
||||
__istream_type&
|
||||
operator=(const __istream_type&);
|
||||
|
||||
|
|
|
|||
|
|
@ -58,9 +58,7 @@
|
|||
|
||||
#pragma GCC system_header
|
||||
|
||||
#ifndef _CPP_BITS_STL_TREE_H
|
||||
#include <bits/stl_tree.h>
|
||||
#endif
|
||||
#include <bits/stl_map.h>
|
||||
#include <bits/stl_multimap.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -170,7 +170,7 @@ namespace std
|
|||
|
||||
private:
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
// Not defined.
|
||||
// Not defined. (Side effect of DR 50.)
|
||||
__ostream_type&
|
||||
operator=(const __ostream_type&);
|
||||
|
||||
|
|
|
|||
|
|
@ -58,9 +58,7 @@
|
|||
|
||||
#pragma GCC system_header
|
||||
|
||||
#ifndef _CPP_BITS_STL_TREE_H /* XXX is this guard needed? */
|
||||
#include <bits/stl_tree.h>
|
||||
#endif
|
||||
#include <bits/stl_set.h>
|
||||
#include <bits/stl_multiset.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -513,6 +513,7 @@ namespace std
|
|||
#endif
|
||||
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
// Side effect of DR 50.
|
||||
private:
|
||||
basic_streambuf(const __streambuf_type&);
|
||||
|
||||
|
|
|
|||
|
|
@ -53,8 +53,9 @@
|
|||
* purpose. It is provided "as is" without express or implied warranty.
|
||||
*/
|
||||
|
||||
/* NOTE: This is an internal header file, included by other STL headers.
|
||||
* You should not attempt to use it directly.
|
||||
/** @file stl_function.h
|
||||
* This is an internal header file, included by other STL headers. You
|
||||
* should not attempt to use it directly.
|
||||
*/
|
||||
|
||||
#ifndef __SGI_STL_INTERNAL_FUNCTION_H
|
||||
|
|
@ -62,115 +63,230 @@
|
|||
|
||||
namespace std
|
||||
{
|
||||
|
||||
// 20.3.1 base classes
|
||||
/** @defgroup s20_3_1_base Functor Base Classes
|
||||
* Function objects, or @e functors, are objects with an @c operator()
|
||||
* defined and accessible. They can be passed as arguments to algorithm
|
||||
* templates and used in place of a function pointer. Not only is the
|
||||
* resulting expressiveness of the library increased, but the generated
|
||||
* code can be more efficient than what you might write by hand. When we
|
||||
* refer to "functors," then, generally we include function pointers in
|
||||
* the description as well.
|
||||
*
|
||||
* Often, functors are only created as temporaries passed to algorithm
|
||||
* calls, rather than being created as named variables.
|
||||
*
|
||||
* Two examples taken from the standard itself follow. To perform a
|
||||
* by-element addition of two vectors @c a and @c b containing @c double,
|
||||
* and put the result in @c a, use
|
||||
* \code
|
||||
* transform (a.begin(), a.end(), b.begin(), a.begin(), plus<double>());
|
||||
* \endcode
|
||||
* To negate every element in @c a, use
|
||||
* \code
|
||||
* transform(a.begin(), a.end(), a.begin(), negate<double>());
|
||||
* \endcode
|
||||
* The addition and negation functions will be inlined directly.
|
||||
*
|
||||
* The standard functiors are derived from structs named @c unary_function
|
||||
* and @c binary_function. These two classes contain nothing but typedefs,
|
||||
* to aid in generic (template) programming. If you write your own
|
||||
* functors, you might consider doing the same.
|
||||
*
|
||||
* @{
|
||||
*/
|
||||
/**
|
||||
* This is one of the @link s20_3_1_base functor base classes @endlink.
|
||||
*/
|
||||
template <class _Arg, class _Result>
|
||||
struct unary_function {
|
||||
typedef _Arg argument_type;
|
||||
typedef _Result result_type;
|
||||
typedef _Arg argument_type; ///< @c argument_type is the type of the argument (no surprises here)
|
||||
typedef _Result result_type; ///< @c result_type is the return type
|
||||
};
|
||||
|
||||
/**
|
||||
* This is one of the @link s20_3_1_base functor base classes @endlink.
|
||||
*/
|
||||
template <class _Arg1, class _Arg2, class _Result>
|
||||
struct binary_function {
|
||||
typedef _Arg1 first_argument_type;
|
||||
typedef _Arg2 second_argument_type;
|
||||
typedef _Result result_type;
|
||||
typedef _Arg1 first_argument_type; ///< the type of the first argument (no surprises here)
|
||||
typedef _Arg2 second_argument_type; ///< the type of the second argument
|
||||
typedef _Result result_type; ///< type of the return type
|
||||
};
|
||||
/** @} */
|
||||
|
||||
// 20.3.2 arithmetic
|
||||
/** @defgroup s20_3_2_arithmetic Arithmetic Classes
|
||||
* Because basic math often needs to be done during an algorithm, the library
|
||||
* provides functors for those operations. See the documentation for
|
||||
* @link s20_3_1_base the base classes @endlink for examples of their use.
|
||||
*
|
||||
* @{
|
||||
*/
|
||||
/// One of the @link s20_3_2_arithmetic math functors @endlink.
|
||||
template <class _Tp>
|
||||
struct plus : public binary_function<_Tp,_Tp,_Tp> {
|
||||
_Tp operator()(const _Tp& __x, const _Tp& __y) const { return __x + __y; }
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_2_arithmetic math functors @endlink.
|
||||
template <class _Tp>
|
||||
struct minus : public binary_function<_Tp,_Tp,_Tp> {
|
||||
_Tp operator()(const _Tp& __x, const _Tp& __y) const { return __x - __y; }
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_2_arithmetic math functors @endlink.
|
||||
template <class _Tp>
|
||||
struct multiplies : public binary_function<_Tp,_Tp,_Tp> {
|
||||
_Tp operator()(const _Tp& __x, const _Tp& __y) const { return __x * __y; }
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_2_arithmetic math functors @endlink.
|
||||
template <class _Tp>
|
||||
struct divides : public binary_function<_Tp,_Tp,_Tp> {
|
||||
_Tp operator()(const _Tp& __x, const _Tp& __y) const { return __x / __y; }
|
||||
};
|
||||
|
||||
// identity_element (not part of the C++ standard).
|
||||
|
||||
template <class _Tp> inline _Tp identity_element(plus<_Tp>) {
|
||||
return _Tp(0);
|
||||
}
|
||||
template <class _Tp> inline _Tp identity_element(multiplies<_Tp>) {
|
||||
return _Tp(1);
|
||||
}
|
||||
|
||||
/// One of the @link s20_3_2_arithmetic math functors @endlink.
|
||||
template <class _Tp>
|
||||
struct modulus : public binary_function<_Tp,_Tp,_Tp>
|
||||
{
|
||||
_Tp operator()(const _Tp& __x, const _Tp& __y) const { return __x % __y; }
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_2_arithmetic math functors @endlink.
|
||||
template <class _Tp>
|
||||
struct negate : public unary_function<_Tp,_Tp>
|
||||
{
|
||||
_Tp operator()(const _Tp& __x) const { return -__x; }
|
||||
};
|
||||
/** @} */
|
||||
|
||||
/** The @c identity_element functions are not part of the C++ standard; SGI
|
||||
* provided them as an extension. Its argument is an operation, and its
|
||||
* return value is the identity element for that operation. It is overloaded
|
||||
* for addition and multiplication, and you can overload it for your own
|
||||
* nefarious operations.
|
||||
*
|
||||
* @addtogroup SGIextensions
|
||||
* @{
|
||||
*/
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Tp> inline _Tp identity_element(plus<_Tp>) {
|
||||
return _Tp(0);
|
||||
}
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Tp> inline _Tp identity_element(multiplies<_Tp>) {
|
||||
return _Tp(1);
|
||||
}
|
||||
/** @} */
|
||||
|
||||
// 20.3.3 comparisons
|
||||
/** @defgroup s20_3_3_comparisons Comparison Classes
|
||||
* The library provides six wrapper functors for all the basic comparisons
|
||||
* in C++, like @c <.
|
||||
*
|
||||
* @{
|
||||
*/
|
||||
/// One of the @link s20_3_3_comparisons comparison functors @endlink.
|
||||
template <class _Tp>
|
||||
struct equal_to : public binary_function<_Tp,_Tp,bool>
|
||||
{
|
||||
bool operator()(const _Tp& __x, const _Tp& __y) const { return __x == __y; }
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_3_comparisons comparison functors @endlink.
|
||||
template <class _Tp>
|
||||
struct not_equal_to : public binary_function<_Tp,_Tp,bool>
|
||||
{
|
||||
bool operator()(const _Tp& __x, const _Tp& __y) const { return __x != __y; }
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_3_comparisons comparison functors @endlink.
|
||||
template <class _Tp>
|
||||
struct greater : public binary_function<_Tp,_Tp,bool>
|
||||
{
|
||||
bool operator()(const _Tp& __x, const _Tp& __y) const { return __x > __y; }
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_3_comparisons comparison functors @endlink.
|
||||
template <class _Tp>
|
||||
struct less : public binary_function<_Tp,_Tp,bool>
|
||||
{
|
||||
bool operator()(const _Tp& __x, const _Tp& __y) const { return __x < __y; }
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_3_comparisons comparison functors @endlink.
|
||||
template <class _Tp>
|
||||
struct greater_equal : public binary_function<_Tp,_Tp,bool>
|
||||
{
|
||||
bool operator()(const _Tp& __x, const _Tp& __y) const { return __x >= __y; }
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_3_comparisons comparison functors @endlink.
|
||||
template <class _Tp>
|
||||
struct less_equal : public binary_function<_Tp,_Tp,bool>
|
||||
{
|
||||
bool operator()(const _Tp& __x, const _Tp& __y) const { return __x <= __y; }
|
||||
};
|
||||
/** @} */
|
||||
|
||||
// 20.3.4 logical operations
|
||||
/** @defgroup s20_3_4_logical Boolean Operations Classes
|
||||
* Here are wrapper functors for Boolean operations: @c &&, @c ||, and @c !.
|
||||
*
|
||||
* @{
|
||||
*/
|
||||
/// One of the @link s20_3_4_logical Boolean operations functors @endlink.
|
||||
template <class _Tp>
|
||||
struct logical_and : public binary_function<_Tp,_Tp,bool>
|
||||
{
|
||||
bool operator()(const _Tp& __x, const _Tp& __y) const { return __x && __y; }
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_4_logical Boolean operations functors @endlink.
|
||||
template <class _Tp>
|
||||
struct logical_or : public binary_function<_Tp,_Tp,bool>
|
||||
{
|
||||
bool operator()(const _Tp& __x, const _Tp& __y) const { return __x || __y; }
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_4_logical Boolean operations functors @endlink.
|
||||
template <class _Tp>
|
||||
struct logical_not : public unary_function<_Tp,bool>
|
||||
{
|
||||
bool operator()(const _Tp& __x) const { return !__x; }
|
||||
};
|
||||
/** @} */
|
||||
|
||||
// 20.3.5 negators
|
||||
/** @defgroup s20_3_5_negators Negators
|
||||
* The functions @c not1 and @c not2 each take a predicate functor
|
||||
* and return an instance of @c unary_negate or
|
||||
* @c binary_negate, respectively. These classes are functors whose
|
||||
* @c operator() performs the stored predicate function and then returns
|
||||
* the negation of the result.
|
||||
*
|
||||
* For example, given a vector of integers and a trivial predicate,
|
||||
* \code
|
||||
* struct IntGreaterThanThree
|
||||
* : public std::unary_function<int, bool>
|
||||
* {
|
||||
* bool operator() (int x) { return x > 3; }
|
||||
* };
|
||||
*
|
||||
* std::find_if (v.begin(), v.end(), not1(IntGreaterThanThree()));
|
||||
* \endcode
|
||||
* The call to @c find_if will locate the first index (i) of @c v for which
|
||||
* "!(v[i] > 3)" is true.
|
||||
*
|
||||
* The not1/unary_negate combination works on predicates taking a single
|
||||
* argument. The not2/binary_negate combination works on predicates which
|
||||
* take two arguments.
|
||||
*
|
||||
* @{
|
||||
*/
|
||||
/// One of the @link s20_3_5_negators negation functors @endlink.
|
||||
template <class _Predicate>
|
||||
class unary_negate
|
||||
: public unary_function<typename _Predicate::argument_type, bool> {
|
||||
|
|
@ -183,6 +299,7 @@ public:
|
|||
}
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_5_negators negation functors @endlink.
|
||||
template <class _Predicate>
|
||||
inline unary_negate<_Predicate>
|
||||
not1(const _Predicate& __pred)
|
||||
|
|
@ -190,6 +307,7 @@ not1(const _Predicate& __pred)
|
|||
return unary_negate<_Predicate>(__pred);
|
||||
}
|
||||
|
||||
/// One of the @link s20_3_5_negators negation functors @endlink.
|
||||
template <class _Predicate>
|
||||
class binary_negate
|
||||
: public binary_function<typename _Predicate::first_argument_type,
|
||||
|
|
@ -206,13 +324,47 @@ public:
|
|||
}
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_5_negators negation functors @endlink.
|
||||
template <class _Predicate>
|
||||
inline binary_negate<_Predicate>
|
||||
not2(const _Predicate& __pred)
|
||||
{
|
||||
return binary_negate<_Predicate>(__pred);
|
||||
}
|
||||
/** @} */
|
||||
|
||||
// 20.3.6 binders
|
||||
/** @defgroup s20_3_6_binder Binder Classes
|
||||
* Binders turn functions/functors with two arguments into functors with
|
||||
* a single argument, storing an argument to be applied later. For
|
||||
* example, an variable @c B of type @c binder1st is constructed from a functor
|
||||
* @c f and an argument @c x. Later, B's @c operator() is called with a
|
||||
* single argument @c y. The return value is the value of @c f(x,y).
|
||||
* @c B can be "called" with various arguments (y1, y2, ...) and will in
|
||||
* turn call @c f(x,y1), @c f(x,y2), ...
|
||||
*
|
||||
* The function @c bind1st is provided to save some typing. It takes the
|
||||
* function and an argument as parameters, and returns an instance of
|
||||
* @c binder1st.
|
||||
*
|
||||
* The type @c binder2nd and its creator function @c bind2nd do the same
|
||||
* thing, but the stored argument is passed as the second parameter instead
|
||||
* of the first, e.g., @c bind2nd(std::minus<float>,1.3) will create a
|
||||
* functor whose @c operator() accepts a floating-point number, subtracts
|
||||
* 1.3 from it, and returns the result. (If @c bind1st had been used,
|
||||
* the functor would perform "1.3 - x" instead.
|
||||
*
|
||||
* Creator-wrapper functions like @c bind1st are intended to be used in
|
||||
* calling algorithms. Their return values will be temporary objects.
|
||||
* (The goal is to not require you to type names like
|
||||
* @c std::binder1st<std::plus<int>> for declaring a variable to hold the
|
||||
* return value from @c bind1st(std::plus<int>,5).
|
||||
*
|
||||
* These become more useful when combined with the composition functions.
|
||||
*
|
||||
* @{
|
||||
*/
|
||||
/// One of the @link s20_3_6_binder binder functors @endlink.
|
||||
template <class _Operation>
|
||||
class binder1st
|
||||
: public unary_function<typename _Operation::second_argument_type,
|
||||
|
|
@ -229,7 +381,7 @@ public:
|
|||
return op(value, __x);
|
||||
}
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
// 109. Missing binders for non-const sequence elements
|
||||
//109. Missing binders for non-const sequence elements
|
||||
typename _Operation::result_type
|
||||
operator()(typename _Operation::second_argument_type& __x) const {
|
||||
return op(value, __x);
|
||||
|
|
@ -237,6 +389,7 @@ public:
|
|||
#endif
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_6_binder binder functors @endlink.
|
||||
template <class _Operation, class _Tp>
|
||||
inline binder1st<_Operation>
|
||||
bind1st(const _Operation& __fn, const _Tp& __x)
|
||||
|
|
@ -245,6 +398,7 @@ bind1st(const _Operation& __fn, const _Tp& __x)
|
|||
return binder1st<_Operation>(__fn, _Arg1_type(__x));
|
||||
}
|
||||
|
||||
/// One of the @link s20_3_6_binder binder functors @endlink.
|
||||
template <class _Operation>
|
||||
class binder2nd
|
||||
: public unary_function<typename _Operation::first_argument_type,
|
||||
|
|
@ -261,7 +415,7 @@ public:
|
|||
return op(__x, value);
|
||||
}
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
// 109. Missing binders for non-const sequence elements
|
||||
//109. Missing binders for non-const sequence elements
|
||||
typename _Operation::result_type
|
||||
operator()(typename _Operation::first_argument_type& __x) const {
|
||||
return op(__x, value);
|
||||
|
|
@ -269,6 +423,7 @@ public:
|
|||
#endif
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_6_binder binder functors @endlink.
|
||||
template <class _Operation, class _Tp>
|
||||
inline binder2nd<_Operation>
|
||||
bind2nd(const _Operation& __fn, const _Tp& __x)
|
||||
|
|
@ -276,9 +431,35 @@ bind2nd(const _Operation& __fn, const _Tp& __x)
|
|||
typedef typename _Operation::second_argument_type _Arg2_type;
|
||||
return binder2nd<_Operation>(__fn, _Arg2_type(__x));
|
||||
}
|
||||
/** @} */
|
||||
|
||||
// unary_compose and binary_compose (extensions, not part of the standard).
|
||||
|
||||
/** As an extension to the binders, SGI provided composition functors and
|
||||
* wrapper functions to aid in their creation. The @c unary_compose
|
||||
* functor is constructed from two functions/functors, @c f and @c g.
|
||||
* Calling @c operator() with a single argument @c x returns @c f(g(x)).
|
||||
* The function @c compose1 takes the two functions and constructs a
|
||||
* @c unary_compose variable for you.
|
||||
*
|
||||
* @c binary_compose is constructed from three functors, @c f, @c g1,
|
||||
* and @c g2. Its @c operator() returns @c f(g1(x),g2(x)). The function
|
||||
* @compose2 takes f, g1, and g2, and constructs the @c binary_compose
|
||||
* instance for you. For example, if @c f returns an int, then
|
||||
* \code
|
||||
* int answer = (compose2(f,g1,g2))(x);
|
||||
* \endcode
|
||||
* is equivalent to
|
||||
* \code
|
||||
* int temp1 = g1(x);
|
||||
* int temp2 = g2(x);
|
||||
* int answer = f(temp1,temp2);
|
||||
* \endcode
|
||||
* But the first form is more compact, and can be passed around as a
|
||||
* functor to other algorithms.
|
||||
*
|
||||
* @addtogroup SGIextensions
|
||||
* @{
|
||||
*/
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Operation1, class _Operation2>
|
||||
class unary_compose
|
||||
: public unary_function<typename _Operation2::argument_type,
|
||||
|
|
@ -296,6 +477,7 @@ public:
|
|||
}
|
||||
};
|
||||
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Operation1, class _Operation2>
|
||||
inline unary_compose<_Operation1,_Operation2>
|
||||
compose1(const _Operation1& __fn1, const _Operation2& __fn2)
|
||||
|
|
@ -303,6 +485,7 @@ compose1(const _Operation1& __fn1, const _Operation2& __fn2)
|
|||
return unary_compose<_Operation1,_Operation2>(__fn1, __fn2);
|
||||
}
|
||||
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Operation1, class _Operation2, class _Operation3>
|
||||
class binary_compose
|
||||
: public unary_function<typename _Operation2::argument_type,
|
||||
|
|
@ -321,6 +504,7 @@ public:
|
|||
}
|
||||
};
|
||||
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Operation1, class _Operation2, class _Operation3>
|
||||
inline binary_compose<_Operation1, _Operation2, _Operation3>
|
||||
compose2(const _Operation1& __fn1, const _Operation2& __fn2,
|
||||
|
|
@ -329,7 +513,29 @@ compose2(const _Operation1& __fn1, const _Operation2& __fn2,
|
|||
return binary_compose<_Operation1,_Operation2,_Operation3>
|
||||
(__fn1, __fn2, __fn3);
|
||||
}
|
||||
/** @} */
|
||||
|
||||
// 20.3.7 adaptors pointers functions
|
||||
/** @defgroup s20_3_7_adaptors Adaptors for pointers to functions
|
||||
* The advantage of function objects over pointers to functions is that
|
||||
* the objects in the standard library declare nested typedefs describing
|
||||
* their argument and result types with uniform names (e.g., @c result_type
|
||||
* from the base classes @c unary_function and @c binary_function).
|
||||
* Sometimes those typedefs are required, not just optional.
|
||||
*
|
||||
* Adaptors are provided to turn pointers to unary (single-argument) and
|
||||
* binary (double-argument) functions into function objects. The long-winded
|
||||
* functor @c pointer_to_unary_function is constructed with a function
|
||||
* pointer @c f, and its @c operator() called with argument @c x returns
|
||||
* @c f(x). The functor @c pointer_to_binary_function does the same thing,
|
||||
* but with a double-argument @c f and @c operator().
|
||||
*
|
||||
* The function @c ptr_fun takes a pointer-to-function @c f and constructs
|
||||
* an instance of the appropriate functor.
|
||||
*
|
||||
* @{
|
||||
*/
|
||||
/// One of the @link s20_3_7_adaptors adaptors for function pointers @endlink.
|
||||
template <class _Arg, class _Result>
|
||||
class pointer_to_unary_function : public unary_function<_Arg, _Result> {
|
||||
protected:
|
||||
|
|
@ -340,12 +546,14 @@ public:
|
|||
_Result operator()(_Arg __x) const { return _M_ptr(__x); }
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_7_adaptors adaptors for function pointers @endlink.
|
||||
template <class _Arg, class _Result>
|
||||
inline pointer_to_unary_function<_Arg, _Result> ptr_fun(_Result (*__x)(_Arg))
|
||||
{
|
||||
return pointer_to_unary_function<_Arg, _Result>(__x);
|
||||
}
|
||||
|
||||
/// One of the @link s20_3_7_adaptors adaptors for function pointers @endlink.
|
||||
template <class _Arg1, class _Arg2, class _Result>
|
||||
class pointer_to_binary_function :
|
||||
public binary_function<_Arg1,_Arg2,_Result> {
|
||||
|
|
@ -360,22 +568,31 @@ public:
|
|||
}
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_7_adaptors adaptors for function pointers @endlink.
|
||||
template <class _Arg1, class _Arg2, class _Result>
|
||||
inline pointer_to_binary_function<_Arg1,_Arg2,_Result>
|
||||
ptr_fun(_Result (*__x)(_Arg1, _Arg2)) {
|
||||
return pointer_to_binary_function<_Arg1,_Arg2,_Result>(__x);
|
||||
}
|
||||
/** @} */
|
||||
|
||||
// identity is an extensions: it is not part of the standard.
|
||||
|
||||
// extension documented next
|
||||
template <class _Tp>
|
||||
struct _Identity : public unary_function<_Tp,_Tp> {
|
||||
_Tp& operator()(_Tp& __x) const { return __x; }
|
||||
const _Tp& operator()(const _Tp& __x) const { return __x; }
|
||||
};
|
||||
|
||||
/** As an extension, SGI provided a functor called @c identity. When a
|
||||
* functor is required but no operations are desired, this can be used as a
|
||||
* pass-through. Its @c operator() returns its argument unchanged.
|
||||
*
|
||||
* @addtogroup SGIextensions
|
||||
*/
|
||||
template <class _Tp> struct identity : public _Identity<_Tp> {};
|
||||
|
||||
// select1st and select2nd are extensions: they are not part of the standard.
|
||||
// extension documented next
|
||||
template <class _Pair>
|
||||
struct _Select1st : public unary_function<_Pair, typename _Pair::first_type> {
|
||||
typename _Pair::first_type& operator()(_Pair& __x) const {
|
||||
|
|
@ -397,10 +614,23 @@ struct _Select2nd : public unary_function<_Pair, typename _Pair::second_type>
|
|||
}
|
||||
};
|
||||
|
||||
/** @c select1st and @c select2nd are extensions provided by SGI. Their
|
||||
* @c operator()s
|
||||
* take a @c std::pair as an argument, and return either the first member
|
||||
* or the second member, respectively. They can be used (especially with
|
||||
* the composition functors) to "strip" data from a sequence before
|
||||
* performing the remainder of an algorithm.
|
||||
*
|
||||
* @addtogroup SGIextensions
|
||||
* @{
|
||||
*/
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Pair> struct select1st : public _Select1st<_Pair> {};
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Pair> struct select2nd : public _Select2nd<_Pair> {};
|
||||
/** @} */
|
||||
|
||||
// project1st and project2nd are extensions: they are not part of the standard
|
||||
// extension documented next
|
||||
template <class _Arg1, class _Arg2>
|
||||
struct _Project1st : public binary_function<_Arg1, _Arg2, _Arg1> {
|
||||
_Arg1 operator()(const _Arg1& __x, const _Arg2&) const { return __x; }
|
||||
|
|
@ -411,16 +641,23 @@ struct _Project2nd : public binary_function<_Arg1, _Arg2, _Arg2> {
|
|||
_Arg2 operator()(const _Arg1&, const _Arg2& __y) const { return __y; }
|
||||
};
|
||||
|
||||
/** The @c operator() of the @c project1st functor takes two arbitrary
|
||||
* arguments and returns the first one, while @c project2nd returns the
|
||||
* second one. They are extensions provided by SGI.
|
||||
*
|
||||
* @addtogroup SGIextensions
|
||||
* @{
|
||||
*/
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Arg1, class _Arg2>
|
||||
struct project1st : public _Project1st<_Arg1, _Arg2> {};
|
||||
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Arg1, class _Arg2>
|
||||
struct project2nd : public _Project2nd<_Arg1, _Arg2> {};
|
||||
/** @} */
|
||||
|
||||
// constant_void_fun, constant_unary_fun, and constant_binary_fun are
|
||||
// extensions: they are not part of the standard. (The same, of course,
|
||||
// is true of the helper functions constant0, constant1, and constant2.)
|
||||
|
||||
// extension documented next
|
||||
template <class _Result>
|
||||
struct _Constant_void_fun {
|
||||
typedef _Result result_type;
|
||||
|
|
@ -453,12 +690,27 @@ struct _Constant_binary_fun {
|
|||
}
|
||||
};
|
||||
|
||||
/** These three functors are each constructed from a single arbitrary
|
||||
* variable/value. Later, their @c operator()s completely ignore any
|
||||
* arguments passed, and return the stored value.
|
||||
* - @c constant_void_fun's @c operator() takes no arguments
|
||||
* - @c constant_unary_fun's @c operator() takes one argument (ignored)
|
||||
* - @c constant_binary_fun's @c operator() takes two arguments (ignored)
|
||||
*
|
||||
* The helper creator functions @c constant0, @c constant1, and
|
||||
* @c constant2 each take a "result" argument and construct variables of
|
||||
* the appropriate functor type.
|
||||
*
|
||||
* @addtogroup SGIextensions
|
||||
* @{
|
||||
*/
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Result>
|
||||
struct constant_void_fun : public _Constant_void_fun<_Result> {
|
||||
constant_void_fun(const _Result& __v) : _Constant_void_fun<_Result>(__v) {}
|
||||
};
|
||||
|
||||
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Result,
|
||||
class _Argument = _Result>
|
||||
struct constant_unary_fun : public _Constant_unary_fun<_Result, _Argument>
|
||||
|
|
@ -467,7 +719,7 @@ struct constant_unary_fun : public _Constant_unary_fun<_Result, _Argument>
|
|||
: _Constant_unary_fun<_Result, _Argument>(__v) {}
|
||||
};
|
||||
|
||||
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Result,
|
||||
class _Arg1 = _Result,
|
||||
class _Arg2 = _Arg1>
|
||||
|
|
@ -478,33 +730,42 @@ struct constant_binary_fun
|
|||
: _Constant_binary_fun<_Result, _Arg1, _Arg2>(__v) {}
|
||||
};
|
||||
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Result>
|
||||
inline constant_void_fun<_Result> constant0(const _Result& __val)
|
||||
{
|
||||
return constant_void_fun<_Result>(__val);
|
||||
}
|
||||
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Result>
|
||||
inline constant_unary_fun<_Result,_Result> constant1(const _Result& __val)
|
||||
{
|
||||
return constant_unary_fun<_Result,_Result>(__val);
|
||||
}
|
||||
|
||||
/// An \link SGIextensions SGI extension \endlink.
|
||||
template <class _Result>
|
||||
inline constant_binary_fun<_Result,_Result,_Result>
|
||||
constant2(const _Result& __val)
|
||||
{
|
||||
return constant_binary_fun<_Result,_Result,_Result>(__val);
|
||||
}
|
||||
/** @} */
|
||||
|
||||
// subtractive_rng is an extension: it is not part of the standard.
|
||||
// Note: this code assumes that int is 32 bits.
|
||||
/** The @c subtractive_rng class is documented on
|
||||
* <a href="http://www.sgi.com/tech/stl/">SGI's site</a>.
|
||||
* Note that this code assumes that @c int is 32 bits.
|
||||
*
|
||||
* @ingroup SGIextensions
|
||||
*/
|
||||
class subtractive_rng : public unary_function<unsigned int, unsigned int> {
|
||||
private:
|
||||
unsigned int _M_table[55];
|
||||
size_t _M_index1;
|
||||
size_t _M_index2;
|
||||
public:
|
||||
/// Returns a number less than the argument.
|
||||
unsigned int operator()(unsigned int __limit) {
|
||||
_M_index1 = (_M_index1 + 1) % 55;
|
||||
_M_index2 = (_M_index2 + 1) % 55;
|
||||
|
|
@ -531,34 +792,38 @@ public:
|
|||
_M_index2 = 31;
|
||||
}
|
||||
|
||||
/// Ctor allowing you to initialize the seed.
|
||||
subtractive_rng(unsigned int __seed) { _M_initialize(__seed); }
|
||||
/// Default ctor; initializes its state with some number you don't see.
|
||||
subtractive_rng() { _M_initialize(161803398u); }
|
||||
};
|
||||
|
||||
|
||||
// Adaptor function objects: pointers to member functions.
|
||||
|
||||
// There are a total of 16 = 2^4 function objects in this family.
|
||||
// (1) Member functions taking no arguments vs member functions taking
|
||||
// one argument.
|
||||
// (2) Call through pointer vs call through reference.
|
||||
// (3) Member function with void return type vs member function with
|
||||
// non-void return type.
|
||||
// (4) Const vs non-const member function.
|
||||
|
||||
// Note that choice (3) is nothing more than a workaround: according
|
||||
// to the draft, compilers should handle void and non-void the same way.
|
||||
// This feature is not yet widely implemented, though. You can only use
|
||||
// member functions returning void if your compiler supports partial
|
||||
// specialization.
|
||||
|
||||
// All of this complexity is in the function objects themselves. You can
|
||||
// ignore it by using the helper function mem_fun and mem_fun_ref,
|
||||
// which create whichever type of adaptor is appropriate.
|
||||
// (mem_fun1 and mem_fun1_ref are no longer part of the C++ standard,
|
||||
// but they are provided for backward compatibility.)
|
||||
|
||||
|
||||
// 20.3.8 adaptors pointers members
|
||||
/** @defgroup s20_3_8_memadaptors Adaptors for pointers to members
|
||||
* There are a total of 16 = 2^4 function objects in this family.
|
||||
* (1) Member functions taking no arguments vs member functions taking
|
||||
* one argument.
|
||||
* (2) Call through pointer vs call through reference.
|
||||
* (3) Member function with void return type vs member function with
|
||||
* non-void return type.
|
||||
* (4) Const vs non-const member function.
|
||||
*
|
||||
* Note that choice (3) is nothing more than a workaround: according
|
||||
* to the draft, compilers should handle void and non-void the same way.
|
||||
* This feature is not yet widely implemented, though. You can only use
|
||||
* member functions returning void if your compiler supports partial
|
||||
* specialization.
|
||||
*
|
||||
* All of this complexity is in the function objects themselves. You can
|
||||
* ignore it by using the helper function mem_fun and mem_fun_ref,
|
||||
* which create whichever type of adaptor is appropriate.
|
||||
* (mem_fun1 and mem_fun1_ref are no longer part of the C++ standard,
|
||||
* but they are provided for backward compatibility.)
|
||||
*
|
||||
* @{
|
||||
*/
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Ret, class _Tp>
|
||||
class mem_fun_t : public unary_function<_Tp*,_Ret> {
|
||||
public:
|
||||
|
|
@ -568,6 +833,7 @@ private:
|
|||
_Ret (_Tp::*_M_f)();
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Ret, class _Tp>
|
||||
class const_mem_fun_t : public unary_function<const _Tp*,_Ret> {
|
||||
public:
|
||||
|
|
@ -577,7 +843,7 @@ private:
|
|||
_Ret (_Tp::*_M_f)() const;
|
||||
};
|
||||
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Ret, class _Tp>
|
||||
class mem_fun_ref_t : public unary_function<_Tp,_Ret> {
|
||||
public:
|
||||
|
|
@ -587,6 +853,7 @@ private:
|
|||
_Ret (_Tp::*_M_f)();
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Ret, class _Tp>
|
||||
class const_mem_fun_ref_t : public unary_function<_Tp,_Ret> {
|
||||
public:
|
||||
|
|
@ -596,6 +863,7 @@ private:
|
|||
_Ret (_Tp::*_M_f)() const;
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Ret, class _Tp, class _Arg>
|
||||
class mem_fun1_t : public binary_function<_Tp*,_Arg,_Ret> {
|
||||
public:
|
||||
|
|
@ -605,6 +873,7 @@ private:
|
|||
_Ret (_Tp::*_M_f)(_Arg);
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Ret, class _Tp, class _Arg>
|
||||
class const_mem_fun1_t : public binary_function<const _Tp*,_Arg,_Ret> {
|
||||
public:
|
||||
|
|
@ -615,6 +884,7 @@ private:
|
|||
_Ret (_Tp::*_M_f)(_Arg) const;
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Ret, class _Tp, class _Arg>
|
||||
class mem_fun1_ref_t : public binary_function<_Tp,_Arg,_Ret> {
|
||||
public:
|
||||
|
|
@ -624,6 +894,7 @@ private:
|
|||
_Ret (_Tp::*_M_f)(_Arg);
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Ret, class _Tp, class _Arg>
|
||||
class const_mem_fun1_ref_t : public binary_function<_Tp,_Arg,_Ret> {
|
||||
public:
|
||||
|
|
@ -633,6 +904,7 @@ private:
|
|||
_Ret (_Tp::*_M_f)(_Arg) const;
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Tp>
|
||||
class mem_fun_t<void, _Tp> : public unary_function<_Tp*,void> {
|
||||
public:
|
||||
|
|
@ -642,6 +914,7 @@ private:
|
|||
void (_Tp::*_M_f)();
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Tp>
|
||||
class const_mem_fun_t<void, _Tp> : public unary_function<const _Tp*,void> {
|
||||
public:
|
||||
|
|
@ -651,6 +924,7 @@ private:
|
|||
void (_Tp::*_M_f)() const;
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Tp>
|
||||
class mem_fun_ref_t<void, _Tp> : public unary_function<_Tp,void> {
|
||||
public:
|
||||
|
|
@ -660,6 +934,7 @@ private:
|
|||
void (_Tp::*_M_f)();
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Tp>
|
||||
class const_mem_fun_ref_t<void, _Tp> : public unary_function<_Tp,void> {
|
||||
public:
|
||||
|
|
@ -669,6 +944,7 @@ private:
|
|||
void (_Tp::*_M_f)() const;
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Tp, class _Arg>
|
||||
class mem_fun1_t<void, _Tp, _Arg> : public binary_function<_Tp*,_Arg,void> {
|
||||
public:
|
||||
|
|
@ -678,6 +954,7 @@ private:
|
|||
void (_Tp::*_M_f)(_Arg);
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Tp, class _Arg>
|
||||
class const_mem_fun1_t<void, _Tp, _Arg>
|
||||
: public binary_function<const _Tp*,_Arg,void> {
|
||||
|
|
@ -688,6 +965,7 @@ private:
|
|||
void (_Tp::*_M_f)(_Arg) const;
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Tp, class _Arg>
|
||||
class mem_fun1_ref_t<void, _Tp, _Arg>
|
||||
: public binary_function<_Tp,_Arg,void> {
|
||||
|
|
@ -698,6 +976,7 @@ private:
|
|||
void (_Tp::*_M_f)(_Arg);
|
||||
};
|
||||
|
||||
/// One of the @link s20_3_8_memadaptors adaptors for member pointers @endlink.
|
||||
template <class _Tp, class _Arg>
|
||||
class const_mem_fun1_ref_t<void, _Tp, _Arg>
|
||||
: public binary_function<_Tp,_Arg,void> {
|
||||
|
|
@ -763,6 +1042,7 @@ template <class _Ret, class _Tp, class _Arg>
|
|||
inline const_mem_fun1_ref_t<_Ret,_Tp,_Arg>
|
||||
mem_fun1_ref(_Ret (_Tp::*__f)(_Arg) const)
|
||||
{ return const_mem_fun1_ref_t<_Ret,_Tp,_Arg>(__f); }
|
||||
/** @} */
|
||||
|
||||
} // namespace std
|
||||
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ inline bool operator==(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
|
|||
return __x.first == __y.first && __x.second == __y.second;
|
||||
}
|
||||
|
||||
/// ...put link to onlinedocs here...
|
||||
/// http://gcc.gnu.org/onlinedocs/libstdc++/20_util/howto.html#pairlt
|
||||
template <class _T1, class _T2>
|
||||
inline bool operator<(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
|
||||
{
|
||||
|
|
@ -134,8 +134,9 @@ inline bool operator>=(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y) {
|
|||
* @return A newly-constructed pair<> object of the appropriate type.
|
||||
*
|
||||
* The standard requires that the objects be passed by reference-to-const,
|
||||
* but LWG issue #181 says they should be passed by const value.
|
||||
*/
|
||||
* but LWG issue #181 says they should be passed by const value. We follow
|
||||
* the LWG by default.
|
||||
*/
|
||||
template <class _T1, class _T2>
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
//181. make_pair() unintended behavior
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ namespace std
|
|||
|
||||
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
|
||||
// 110 istreambuf_iterator::equal not const
|
||||
// NB: there is also number 111 pending on this function.
|
||||
// NB: there is also number 111 (NAD, Future) pending on this function.
|
||||
bool
|
||||
equal(const istreambuf_iterator& __b) const
|
||||
{
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ namespace std
|
|||
|
||||
public:
|
||||
// the public interface
|
||||
/** Returns an \e implementation-defined byte string; this is not
|
||||
/** Returns an @e implementation-defined byte string; this is not
|
||||
* portable between compilers! */
|
||||
const char* name() const
|
||||
{ return __name; }
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue