mirror/gcc
2
0
Fork 0
mirror of git://gcc.gnu.org/git/gcc.git synced 2025-03-28 22:11:21 +08:00
Code Issues Packages Projects Releases Wiki Activity

*: Populate with regenerated files.

Browse Source 
2008-02-11  Benjamin Kosnik  <bkoz@redhat.com>

	* doc/html/*: Populate with regenerated files.

From-SVN: r132251
This commit is contained in:
Benjamin Kosnik 2008-02-12 02:39:33 +00:00 committed by Benjamin Kosnik
parent 620039adfb
commit 46abada07f
121 changed files with 19357 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
libstdc++-v3/ChangeLog
View File

@ -1,3 +1,7 @@
2008-02-11 Benjamin Kosnik <bkoz@redhat.com>
* doc/html/*: Populate with regenerated files.
2008-02-11 Benjamin Kosnik <bkoz@redhat.com>
* doc/html/*: Remove all but contents of ext/pb_ds.

48
libstdc++-v3/doc/html/api.html Normal file
View File

@ -0,0 +1,48 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>API and Source Level Documentation</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk02.html" title="" /><link rel="prev" href="bk02.html" title="" /><link rel="next" href="bk03.html" title="" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">API and Source Level Documentation</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk02.html">Prev</a> </td><th width="60%" align="center"></th><td width="20%" align="right"> <a accesskey="n" href="bk03.html">Next</a></td></tr></table><hr /></div><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="api"></a>API and Source Level Documentation</h2></div><div><p class="copyright">Copyright ©
2008
<a class="ulink" href="http://fsf.org" target="_top">FSF
</a>
</p></div><div><div class="legalnotice"><a id="id330876"></a><p>
<a class="ulink" href="17_intro/license.html" target="_top">License
</a>
</p></div></div></div><hr /></div><p>
The GNU C++ library sources have been specially formatted so that with the
proper invocation of another tool (Doxygen), a set of HTML pages
are generated from the sources files themselves. The resultant
documentation is referred to as Source Level Documentation, and is
useful for examining the signatures of public member functions for
the library classes, finding out what is in a particular include
file, looking at inheritance diagrams, etc.
</p><p>
The source-level documentation for the most recent releases can be
viewed online:
</p><div class="itemizedlist"><ul type="disc"><li><p>
<a class="ulink" href="libstdc++-html-USERS-3.4/index.html" target="_top">for the 3.4 release
</a>
</p></li><li><p>
<a class="ulink" href="libstdc++-html-USERS-4.1/index.html" target="_top">for the 4.1 release
</a>
</p></li><li><p>
<a class="ulink" href="libstdc++-html-USERS-4.2/index.html" target="_top">for the 4.2 release
</a>
</p></li><li><p>
<a class="ulink" href="latest-doxygen/index.html" target="_top">"the latest collection"
</a>
(For the main development tree; see the date on the first page.)
</p></li></ul></div><p>
This generated HTML collection, as above, is also available for download in the libstdc++ snapshots directory at
<code class="literal">&lt;URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/doxygen/&gt;</code>.
You will almost certainly need to use one of the
<a class="ulink" href="http://gcc.gnu.org/mirrors.html" target="_top">mirror sites</a> to download
the tarball. After unpacking, simply load libstdc++-html-*/index.html
into a browser.
</p><p>
Documentation for older releases is available for download only, not
online viewing.
</p><p>
In addition, an initial set of man pages are also available in the
same place as the HTML collections. Start with C++Intro(3).
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="spine.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>

3
libstdc++-v3/doc/html/bk02.html Normal file
View File

@ -0,0 +1,3 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="prev" href="manual/backwards.html" title="Backwards Compatibility" /><link rel="next" href="api.html" title="API and Source Level Documentation" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="manual/backwards.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr></table><hr /></div><div class="book" lang="en" xml:lang="en"><div class="titlepage"><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="article"><a href="api.html">API and Source Level Documentation</a></span></dt></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="manual/backwards.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Backwards Compatibility </td><td width="20%" align="center"><a accesskey="h" href="spine.html">Home</a></td><td width="40%" align="right" valign="top"> API and Source Level Documentation</td></tr></table></div></body></html>

3
libstdc++-v3/doc/html/bk03.html Normal file
View File

@ -0,0 +1,3 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="prev" href="api.html" title="API and Source Level Documentation" /><link rel="next" href="faq.html" title="Frequently Asked Questions" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="api.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="faq.html">Next</a></td></tr></table><hr /></div><div class="book" lang="en" xml:lang="en"><div class="titlepage"><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="article"><a href="faq.html">Frequently Asked Questions</a></span></dt></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="api.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="faq.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">API and Source Level Documentation </td><td width="20%" align="center"><a accesskey="h" href="spine.html">Home</a></td><td width="40%" align="right" valign="top"> Frequently Asked Questions</td></tr></table></div></body></html>

873
libstdc++-v3/doc/html/faq.html Normal file
View File

@ -0,0 +1,873 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Frequently Asked Questions</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk03.html" title="" /><link rel="prev" href="bk03.html" title="" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Frequently Asked Questions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk03.html">Prev</a> </td><th width="60%" align="center"></th><td width="20%" align="right"> </td></tr></table><hr /></div><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="faq"></a>Frequently Asked Questions</h2></div><div><p class="copyright">Copyright ©
2008
<a class="ulink" href="http://fsf.org" target="_top">FSF</a>
</p></div></div><hr /></div><div class="qandaset"><dl><dt>1. <a href="faq.html#faq.info">General Information</a></dt><dd><dl><dt>1.1. <a href="faq.html#faq.what">
What is libstdc++?
</a></dt><dt>1.2. <a href="faq.html#faq.why">
Why should I use libstdc++?
</a></dt><dt>1.3. <a href="faq.html#faq.who">
Who's in charge of it?
</a></dt><dt>1.4. <a href="faq.html#faq.when">
When is libstdc++ going to be finished?
</a></dt><dt>1.5. <a href="faq.html#faq.how">
How do I contribute to the effort?
</a></dt><dt>1.6. <a href="faq.html#faq.whereis_old">
What happened to the older libg++? I need that!
</a></dt><dt>1.7. <a href="faq.html#faq.more_questions">
What if I have more questions?
</a></dt></dl></dd><dt>2. <a href="faq.html#faq.license">License</a></dt><dd><dl><dt>2.1. <a href="faq.html#faq.license.what">
What are the license terms for libstdc++?
</a></dt><dt>2.2. <a href="faq.html#faq.license.any_program">
So any program which uses libstdc++ falls under the GPL?
</a></dt><dt>2.3. <a href="faq.html#faq.license.lgpl">
How is that different from the GNU {Lesser,Library} GPL?
</a></dt><dt>2.4. <a href="faq.html#faq.license.what_restrictions">
I see. So, what restrictions are there on programs that use the library?
</a></dt></dl></dd><dt>3. <a href="faq.html#faq.installation">Installation</a></dt><dd><dl><dt>3.1. <a href="faq.html#faq.how_to_install">How do I install libstdc++?
</a></dt><dt>3.2. <a href="faq.html#faq.how_to_get_sources">How does one get current libstdc++ sources?
</a></dt><dt>3.3. <a href="faq.html#faq.how_to_test">How do I know if it works?
</a></dt><dt>3.4. <a href="faq.html#faq.how_to_set_paths">How do I insure that the dynamically linked library will be found?
</a></dt><dt>3.5. <a href="faq.html#faq.what_is_libsupcxx">
What's libsupc++?
</a></dt><dt>3.6. <a href="faq.html#faq.size">
This library is HUGE!
</a></dt></dl></dd><dt>4. <a href="faq.html#faq.platform-specific">Platform-Specific Issues</a></dt><dd><dl><dt>4.1. <a href="faq.html#faq.other_compilers">
Can libstdc++ be used with non-GNU compilers?
</a></dt><dt>4.2. <a href="faq.html#faq.solaris_long_long">
No 'long long' type on Solaris?
</a></dt><dt>4.3. <a href="faq.html#faq.predefined">
_XOPEN_SOURCE and _GNU_SOURCE are always defined?
</a></dt><dt>4.4. <a href="faq.html#faq.darwin_ctype">
Mac OS X ctype.h is broken! How can I fix it?
</a></dt><dt>4.5. <a href="faq.html#faq.threads_i386">
Threading is broken on i386?
</a></dt><dt>4.6. <a href="faq.html#faq.atomic_mips">
MIPS atomic operations
</a></dt><dt>4.7. <a href="faq.html#faq.linux_glibc">
Recent GNU/Linux glibc required?
</a></dt><dt>4.8. <a href="faq.html#faq.freebsd_wchar">
Can't use wchar_t/wstring on FreeBSD
</a></dt></dl></dd><dt>5. <a href="faq.html#faq.known_bugs">Known Bugs</a></dt><dd><dl><dt>5.1. <a href="faq.html#faq.what_works">
What works already?
</a></dt><dt>5.2. <a href="faq.html#faq.standard_bugs">
Bugs in the ISO C++ language or library specification
</a></dt><dt>5.3. <a href="faq.html#faq.compiler_bugs">
Bugs in the compiler (gcc/g++) and not libstdc++
</a></dt></dl></dd><dt>6. <a href="faq.html#faq.known_non-bugs">Known Non-Bugs</a></dt><dd><dl><dt>6.1. <a href="faq.html#faq.stream_reopening_fails">
Reopening a stream fails
</a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose">
-Weffc++ complains too much
</a></dt><dt>6.3. <a href="faq.html#faq.ambiguous_overloads">
Ambiguous overloads after including an old-style header
</a></dt><dt>6.4. <a href="faq.html#faq.v2_headers">
The g++-3 headers are not ours
</a></dt><dt>6.5. <a href="faq.html#faq.boost_concept_checks">
Errors about *Concept and
constraints in the STL
</a></dt><dt>6.6. <a href="faq.html#faq.dlopen_crash">
Program crashes when using library code in a
dynamically-loaded library
</a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">
“Memory leaks” in containers
</a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">
list::size() is O(n)!
</a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
Aw, that's easy to fix!
</a></dt></dl></dd><dt>7. <a href="faq.html#faq.misc">Miscellaneous</a></dt><dd><dl><dt>7.1. <a href="faq.html#faq.iterator_as_pod">
string::iterator is not char*; vector&lt;T&gt;::iterator is not T*
</a></dt><dt>7.2. <a href="faq.html#faq.what_is_next">
What's next after libstdc++?
</a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl">
What about the STL from SGI?
</a></dt><dt>7.4. <a href="faq.html#faq.extensions_and_backwards_compat">
Extensions and Backward Compatibility
</a></dt><dt>7.5. <a href="faq.html#faq.tr1_support">
Does libstdc++ support TR1?
</a></dt><dt>7.6. <a href="faq.html#faq.get_iso_cxx">How do I get a copy of the ISO C++ Standard?
</a></dt><dt>7.7. <a href="faq.html#faq.what_is_abi">
What's an ABI and why is it so messy?
</a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity">
How do I make std::vector&lt;T&gt;::capacity() == std::vector&lt;T&gt;::size?
</a></dt></dl></dd></dl><table border="0" summary="Q and A Set"><col align="left" width="1%" /><tbody><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.info"></a>1. General Information</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>1.1. <a href="faq.html#faq.what">
What is libstdc++?
</a></dt><dt>1.2. <a href="faq.html#faq.why">
Why should I use libstdc++?
</a></dt><dt>1.3. <a href="faq.html#faq.who">
Who's in charge of it?
</a></dt><dt>1.4. <a href="faq.html#faq.when">
When is libstdc++ going to be finished?
</a></dt><dt>1.5. <a href="faq.html#faq.how">
How do I contribute to the effort?
</a></dt><dt>1.6. <a href="faq.html#faq.whereis_old">
What happened to the older libg++? I need that!
</a></dt><dt>1.7. <a href="faq.html#faq.more_questions">
What if I have more questions?
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what"></a><a id="faq.what.q"></a><p><b>1.1.</b></p></td><td align="left" valign="top"><p>
What is libstdc++?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.what.a"></a></td><td align="left" valign="top"><p>
The GNU Standard C++ Library v3 is an ongoing project to
implement the ISO 14882 Standard C++ library as described in
chapters 17 through 27 and annex D. For those who want to see
exactly how far the project has come, or just want the latest
bleeding-edge code, the up-to-date source is available over
anonymous SVN, and can even be browsed over
the <a class="ulink" href="http://gcc.gnu.org/svn.html" target="_top">web</a>.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.why"></a><a id="q-why"></a><p><b>1.2.</b></p></td><td align="left" valign="top"><p>
Why should I use libstdc++?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-why"></a></td><td align="left" valign="top"><p>
The completion of the ISO C++ standardization gave the C++
community a powerful set of reuseable tools in the form of the C++
Standard Library. However, all existing C++ implementations are
(as the Draft Standard used to say) “<span class="quote">incomplet and
incorrekt</span>”, and many suffer from limitations of the compilers
that use them.
</p><p>
The GNU compiler collection
(<span class="command"><strong>gcc</strong></span>, <span class="command"><strong>g++</strong></span>, etc) is widely
considered to be one of the leading compilers in the world. Its
development is overseen by the
<a class="ulink" href="http://gcc.gnu.org/" target="_top">GCC team</a>. All of
the rapid development and near-legendary
<a class="ulink" href="http://gcc.gnu.org/buildstat.html" target="_top">portability</a>
that are the hallmarks of an open-source project are being
applied to libstdc++.
</p><p>
That means that all of the Standard classes and functions will be
freely available and fully compliant. (Such as
<code class="classname">string</code>,
<code class="classname">vector&lt;&gt;</code>, iostreams, and algorithms.)
Programmers will no longer need to “<span class="quote">roll their own</span>”
nor be worried about platform-specific incompatibilities.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.who"></a><a id="q-who"></a><p><b>1.3.</b></p></td><td align="left" valign="top"><p>
Who's in charge of it?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-who"></a></td><td align="left" valign="top"><p>
The libstdc++ project is contributed to by several developers
all over the world, in the same way as GCC or Linux.
Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, Ulrich Drepper,
Loren James Rittle, and Paolo Carlini are the lead maintainers of
the SVN archive.
</p><p>
Development and discussion is held on the libstdc++ mailing
list. Subscribing to the list, or searching the list
archives, is open to everyone. You can read instructions for
doing so on the <a class="ulink" href="http://gcc.gnu.org/libstdc++/" target="_top">homepage</a>.
If you have questions, ideas, code, or are just curious, sign up!
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.when"></a><a id="q-when"></a><p><b>1.4.</b></p></td><td align="left" valign="top"><p>
When is libstdc++ going to be finished?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-when"></a></td><td align="left" valign="top"><p>
Nathan Myers gave the best of all possible answers, responding to
a Usenet article asking this question: <span class="emphasis"><em>Sooner, if you
help.</em></span>
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how"></a><a id="q-how"></a><p><b>1.5.</b></p></td><td align="left" valign="top"><p>
How do I contribute to the effort?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how"></a></td><td align="left" valign="top"><p>
Here is <a class="ulink" href="../17_intro/contribute.html" target="_top">a page devoted to
this topic</a>. Subscribing to the mailing list (see above, or
the homepage) is a very good idea if you have something to
contribute, or if you have spare time and want to
help. Contributions don't have to be in the form of source code;
anybody who is willing to help write documentation, for example,
or has found a bug in code that we all thought was working and is
willing to provide details, is more than welcome!
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.whereis_old"></a><a id="q-whereis_old"></a><p><b>1.6.</b></p></td><td align="left" valign="top"><p>
What happened to the older libg++? I need that!
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-whereis_old"></a></td><td align="left" valign="top"><p>
The most recent libg++ README states that libg++ is no longer
being actively maintained. It should not be used for new
projects, and is only being kicked along to support older code.
</p><p>
More information in the <a class="link" href="manual/backwards.html" title="Backwards Compatibility">backwards compatibility documentation</a>
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.more_questions"></a><a id="q-more_questions"></a><p><b>1.7.</b></p></td><td align="left" valign="top"><p>
What if I have more questions?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-more_questions"></a></td><td align="left" valign="top"><p>
If you have read the README file, and your question remains
unanswered, then just ask the mailing list. At present, you do not
need to be subscribed to the list to send a message to it. More
information is available on the homepage (including how to browse
the list archives); to send a message to the list,
use <code class="email">&lt;<a class="email" href="mailto:libstdc++@gcc.gnu.org">libstdc++@gcc.gnu.org</a>&gt;</code>.
</p><p>
If you have a question that you think should be included
here, or if you have a question <span class="emphasis"><em>about</em></span> a question/answer
here, please send email to the libstdc++ mailing list, as above.
</p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.license"></a>2. License</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>2.1. <a href="faq.html#faq.license.what">
What are the license terms for libstdc++?
</a></dt><dt>2.2. <a href="faq.html#faq.license.any_program">
So any program which uses libstdc++ falls under the GPL?
</a></dt><dt>2.3. <a href="faq.html#faq.license.lgpl">
How is that different from the GNU {Lesser,Library} GPL?
</a></dt><dt>2.4. <a href="faq.html#faq.license.what_restrictions">
I see. So, what restrictions are there on programs that use the library?
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.what"></a><a id="q-license.what"></a><p><b>2.1.</b></p></td><td align="left" valign="top"><p>
What are the license terms for libstdc++?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what"></a></td><td align="left" valign="top"><p>
See <a class="link" href="manual/bk01pt01ch01s02.html" title="License">our license description</a>
for these and related questions.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.any_program"></a><a id="q-license.any_program"></a><p><b>2.2.</b></p></td><td align="left" valign="top"><p>
So any program which uses libstdc++ falls under the GPL?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.any_program"></a></td><td align="left" valign="top"><p>
No. The special exception permits use of the library in
proprietary applications.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.lgpl"></a><a id="q-license.lgpl"></a><p><b>2.3.</b></p></td><td align="left" valign="top"><p>
How is that different from the GNU {Lesser,Library} GPL?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.lgpl"></a></td><td align="left" valign="top"><p>
The LGPL requires that users be able to replace the LGPL code with a
modified version; this is trivial if the library in question is a C
shared library. But there's no way to make that work with C++, where
much of the library consists of inline functions and templates, which
are expanded inside the code that uses the library. So to allow people
to replace the library code, someone using the library would have to
distribute their own source, rendering the LGPL equivalent to the GPL.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.what_restrictions"></a><a id="q-license.what_restrictions"></a><p><b>2.4.</b></p></td><td align="left" valign="top"><p>
I see. So, what restrictions are there on programs that use the library?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what_restrictions"></a></td><td align="left" valign="top"><p>
None. We encourage such programs to be released as open source,
but we won't punish you or sue you if you choose otherwise.
</p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.installation"></a>3. Installation</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>3.1. <a href="faq.html#faq.how_to_install">How do I install libstdc++?
</a></dt><dt>3.2. <a href="faq.html#faq.how_to_get_sources">How does one get current libstdc++ sources?
</a></dt><dt>3.3. <a href="faq.html#faq.how_to_test">How do I know if it works?
</a></dt><dt>3.4. <a href="faq.html#faq.how_to_set_paths">How do I insure that the dynamically linked library will be found?
</a></dt><dt>3.5. <a href="faq.html#faq.what_is_libsupcxx">
What's libsupc++?
</a></dt><dt>3.6. <a href="faq.html#faq.size">
This library is HUGE!
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_install"></a><a id="q-how_to_install"></a><p><b>3.1.</b></p></td><td align="left" valign="top"><p>How do I install libstdc++?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_install"></a></td><td align="left" valign="top"><p>
Often libstdc++ comes pre-installed as an integral part of many
existing Linux and Unix systems, as well as many embedded
development tools. It may be necessary to install extra
development packages to get the headers, or the documentation, or
the source: please consult your vendor for details.
</p><p>
To build and install from the GNU GCC sources, please consult the
<a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/install.html" target="_top">install
documentation</a> for detailed
instructions. You may wish to browse those files ahead
of time to get a feel for what's required.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_get_sources"></a><a id="q-how_to_get_sources"></a><p><b>3.2.</b></p></td><td align="left" valign="top"><p>How does one get current libstdc++ sources?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_get_sources"></a></td><td align="left" valign="top"><p>
Libstdc++ sources for all official releases can be obtained as
part of the GCC sources, available from various sites and
mirrors. A full <a class="ulink" href="http://gcc.gnu.org/mirrors.html" target="_top">list of
download sites</a> is provided on the main GCC site.
</p><p>
Current libstdc++ sources can always be checked out of the main
GCC source repository using the appropriate version control
tool. At this time, that tool
is <span class="application">Subversion</span>.
</p><p>
<span class="application">Subversion</span>, or <acronym class="acronym">SVN</acronym>, is
one of several revision control packages. It was selected for GNU
projects because it's free (speech), free (beer), and very high
quality. The <a class="ulink" href="http://subversion.tigris.org" target="_top"> Subversion
home page</a> has a better description.
</p><p>
The “<span class="quote">anonymous client checkout</span>” feature of SVN is
similar to anonymous FTP in that it allows anyone to retrieve
the latest libstdc++ sources.
</p><p>
For more information
see <a class="ulink" href="http://gcc.gnu.org/svn.html" target="_top"><acronym class="acronym">SVN</acronym>
details</a>.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_test"></a><a id="q-how_to_test"></a><p><b>3.3.</b></p></td><td align="left" valign="top"><p>How do I know if it works?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_test"></a></td><td align="left" valign="top"><p>
Libstdc++ comes with its own validation testsuite, which includes
conformance testing, regression testing, ABI testing, and
performance testing. Please consult the
<a class="ulink" href="http://gcc.gnu.org/install/test.html" target="_top">testing
documentation</a> for more details.
</p><p>
If you find bugs in the testsuite programs themselves, or if you
think of a new test program that should be added to the suite,
<span class="emphasis"><em>please</em></span> write up your idea and send it to the list!
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_set_paths"></a><a id="q-how_to_set_paths"></a><p><b>3.4.</b></p></td><td align="left" valign="top"><p>How do I insure that the dynamically linked library will be found?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_set_paths"></a></td><td align="left" valign="top"><p>
Depending on your platform and library version, the error message might
be similar to one of the following:
</p><pre class="screen">
./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
/usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found
</pre><p>
This doesn't mean that the shared library isn't installed, only
that the dynamic linker can't find it. When a dynamically-linked
executable is run the linker finds and loads the required shared
libraries by searching a pre-configured list of directories. If
the directory where you've installed libstdc++ is not in this list
then the libraries won't be found. The simplest way to fix this is
to use the <code class="literal">LD_LIBRARY_PATH</code> environment variable,
which is a colon-separated list of directories in which the linker
will search for shared libraries:
</p><pre class="screen">
LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
</pre><p>
The exact environment variable to use will depend on your
platform, e.g. DYLD_LIBRARY_PATH for Darwin,
LD_LIBRARY_PATH_32/LD_LIBRARY_PATH_64 for Solaris 32-/64-bit,
LD_LIBRARYN32_PATH/LD_LIBRARY64_PATH for Irix N32/64-bit ABIs and
SHLIB_PATH for HP-UX.
</p><p>
See the man pages for <span class="command"><strong>ld</strong></span>, <span class="command"><strong>ldd</strong></span>
and <span class="command"><strong>ldconfig</strong></span> for more information. The dynamic
linker has different names on different platforms but the man page
is usually called something such as <code class="filename">ld.so/rtld/dld.so</code>.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_libsupcxx"></a><a id="q-what_is_libsupcxx"></a><p><b>3.5.</b></p></td><td align="left" valign="top"><p>
What's libsupc++?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_libsupcxx"></a></td><td align="left" valign="top"><p>
If the only functions from <code class="filename">libstdc++.a</code>
which you need are language support functions (those listed in
<a class="ulink" href="../18_support/howto.html" target="_top">clause 18</a> of the
standard, e.g., <code class="function">new</code> and
<code class="function">delete</code>), then try linking against
<code class="filename">libsupc++.a</code>, which is a subset of
<code class="filename">libstdc++.a</code>. (Using <span class="command"><strong>gcc</strong></span>
instead of <span class="command"><strong>g++</strong></span> and explicitly linking in
<code class="filename">libsupc++.a</code> via <code class="literal">-lsupc++</code>
for the final link step will do it). This library contains only
those support routines, one per object file. But if you are
using anything from the rest of the library, such as IOStreams
or vectors, then you'll still need pieces from
<code class="filename">libstdc++.a</code>.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.size"></a><a id="q-size"></a><p><b>3.6.</b></p></td><td align="left" valign="top"><p>
This library is HUGE!
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size"></a></td><td align="left" valign="top"><p>
Usually the size of libraries on disk isn't noticeable. When a
link editor (or simply “<span class="quote">linker</span>”) pulls things from a
static archive library, only the necessary object files are copied
into your executable, not the entire library. Unfortunately, even
if you only need a single function or variable from an object file,
the entire object file is extracted. (There's nothing unique to C++
or libstdc++ about this; it's just common behavior, given here
for background reasons.)
</p><p>
Some of the object files which make up libstdc++.a are rather large.
If you create a statically-linked executable with
<code class="literal">-static</code>, those large object files are suddenly part
of your executable. Historically the best way around this was to
only place a very few functions (often only a single one) in each
source/object file; then extracting a single function is the same
as extracting a single .o file. For libstdc++ this is only
possible to a certain extent; the object files in question contain
template classes and template functions, pre-instantiated, and
splitting those up causes severe maintenance headaches.
</p><p>
On supported platforms, libstdc++ takes advantage of garbage
collection in the GNU linker to get a result similar to separating
each symbol into a separate source and object files. On these platforms,
GNU ld can place each function and variable into its own
section in a .o file. The GNU linker can then perform garbage
collection on unused sections; this reduces the situation to only
copying needed functions into the executable, as before, but all
happens automatically.
</p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.platform-specific"></a>4. Platform-Specific Issues</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>4.1. <a href="faq.html#faq.other_compilers">
Can libstdc++ be used with non-GNU compilers?
</a></dt><dt>4.2. <a href="faq.html#faq.solaris_long_long">
No 'long long' type on Solaris?
</a></dt><dt>4.3. <a href="faq.html#faq.predefined">
_XOPEN_SOURCE and _GNU_SOURCE are always defined?
</a></dt><dt>4.4. <a href="faq.html#faq.darwin_ctype">
Mac OS X ctype.h is broken! How can I fix it?
</a></dt><dt>4.5. <a href="faq.html#faq.threads_i386">
Threading is broken on i386?
</a></dt><dt>4.6. <a href="faq.html#faq.atomic_mips">
MIPS atomic operations
</a></dt><dt>4.7. <a href="faq.html#faq.linux_glibc">
Recent GNU/Linux glibc required?
</a></dt><dt>4.8. <a href="faq.html#faq.freebsd_wchar">
Can't use wchar_t/wstring on FreeBSD
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.other_compilers"></a><a id="q-other_compilers"></a><p><b>4.1.</b></p></td><td align="left" valign="top"><p>
Can libstdc++ be used with non-GNU compilers?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-other_compilers"></a></td><td align="left" valign="top"><p>
Perhaps.
</p><p>
Since the goal of ISO Standardization is for all C++
implementations to be able to share code, libstdc++ should be
usable under any ISO-compliant compiler, at least in theory.
</p><p>
However, the reality is that libstdc++ is targeted and optimized
for GCC/g++. This means that often libstdc++ uses specific,
non-standard features of g++ that are not present in older
versions of proprietary compilers. It may take as much as a year or two
after an official release of GCC that contains these features for
proprietary tools support these constructs.
</p><p>
In the near past, specific released versions of libstdc++ have
been known to work with versions of the EDG C++ compiler, and
vendor-specific proprietary C++ compilers such as the Intel ICC
C++ compiler.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.solaris_long_long"></a><a id="q-solaris_long_long"></a><p><b>4.2.</b></p></td><td align="left" valign="top"><p>
No 'long long' type on Solaris?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-solaris_long_long"></a></td><td align="left" valign="top"><p>
By default we try to support the C99 <span class="type">long long</span> type.
This requires that certain functions from your C library be present.
</p><p>
Up through release 3.0.2 the platform-specific tests performed by
libstdc++ were too general, resulting in a conservative approach
to enabling the <span class="type">long long</span> code paths. The most
commonly reported platform affected was Solaris.
</p><p>
This has been fixed for libstdc++ releases greater than 3.0.3.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.predefined"></a><a id="q-predefined"></a><p><b>4.3.</b></p></td><td align="left" valign="top"><p>
<code class="constant">_XOPEN_SOURCE</code> and <code class="constant">_GNU_SOURCE</code> are always defined?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-predefined"></a></td><td align="left" valign="top"><p>On Solaris, g++ (but not gcc) always defines the preprocessor
macro <code class="constant">_XOPEN_SOURCE</code>. On GNU/Linux, the same happens
with <code class="constant">_GNU_SOURCE</code>. (This is not an exhaustive list;
other macros and other platforms are also affected.)
</p><p>These macros are typically used in C library headers, guarding new
versions of functions from their older versions. The C++ standard
library includes the C standard library, but it requires the C90
version, which for backwards-compatibility reasons is often not the
default for many vendors.
</p><p>More to the point, the C++ standard requires behavior which is only
available on certain platforms after certain symbols are defined.
Usually the issue involves I/O-related typedefs. In order to
ensure correctness, the compiler simply predefines those symbols.
</p><p>Note that it's not enough to #define them only when the library is
being built (during installation). Since we don't have an 'export'
keyword, much of the library exists as headers, which means that
the symbols must also be defined as your programs are parsed and
compiled.
</p><p>To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in
the gcc config headers for your target (and try changing them to
see what happens when building complicated code). You can also run
<span class="command"><strong>g++ -E -dM - &lt; /dev/null"</strong></span> to display
a list of predefined macros for any particular installation.
</p><p>This has been discussed on the mailing lists
<a class="ulink" href="http://gcc.gnu.org/cgi-bin/htsearch?method=and&amp;format=builtin-long&amp;sort=score&amp;words=_XOPEN_SOURCE+Solaris" target="_top">quite a bit</a>.
</p><p>This method is something of a wart. We'd like to find a cleaner
solution, but nobody yet has contributed the time.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.darwin_ctype"></a><a id="q-darwin_ctype"></a><p><b>4.4.</b></p></td><td align="left" valign="top"><p>
Mac OS X <code class="filename">ctype.h</code> is broken! How can I fix it?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-darwin_ctype"></a></td><td align="left" valign="top"><p>This is a long-standing bug in the OS X support. Fortunately,
the patch is quite simple, and well-known.
<a class="ulink" href="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html" target="_top"> Here's a
link to the solution</a>.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.threads_i386"></a><a id="q-threads_i386"></a><p><b>4.5.</b></p></td><td align="left" valign="top"><p>
Threading is broken on i386?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-threads_i386"></a></td><td align="left" valign="top"><p>
</p><p>Support for atomic integer operations is/was broken on i386
platforms. The assembly code accidentally used opcodes that are
only available on the i486 and later. So if you configured GCC
to target, for example, i386-linux, but actually used the programs
on an i686, then you would encounter no problems. Only when
actually running the code on a i386 will the problem appear.
</p><p>This is fixed in 3.2.2.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.atomic_mips"></a><a id="q-atomic_mips"></a><p><b>4.6.</b></p></td><td align="left" valign="top"><p>
MIPS atomic operations
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-atomic_mips"></a></td><td align="left" valign="top"><p>
The atomic locking routines for MIPS targets requires MIPS II
and later. A patch went in just after the 3.3 release to
make mips* use the generic implementation instead. You can also
configure for mipsel-elf as a workaround.
</p><p>
The mips*-*-linux* port continues to use the MIPS II routines, and more
work in this area is expected.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.linux_glibc"></a><a id="q-linux_glibc"></a><p><b>4.7.</b></p></td><td align="left" valign="top"><p>
Recent GNU/Linux glibc required?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-linux_glibc"></a></td><td align="left" valign="top"><p>When running on GNU/Linux, libstdc++ 3.2.1 (shared library version
5.0.1) and later uses localization and formatting code from the system
C library (glibc) version 2.2.5. That version of glibc is over a
year old and contains necessary bugfixes. Many GNU/Linux distros make
glibc version 2.3.x available now.
</p><p>The guideline is simple: the more recent the C++ library, the
more recent the C library. (This is also documented in the main
GCC installation instructions.)
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.freebsd_wchar"></a><a id="q-freebsd_wchar"></a><p><b>4.8.</b></p></td><td align="left" valign="top"><p>
Can't use wchar_t/wstring on FreeBSD
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-freebsd_wchar"></a></td><td align="left" valign="top"><p>
Older versions of FreeBSD's C library do not have sufficient
support for wide character functions, and as a result the
libstdc++ configury decides that wchar_t support should be
disabled. In addition, the libstdc++ platform checks that
enabled <span class="type">wchar_t</span> were quite strict, and not granular
enough to detect when the minimal support to
enable <span class="type">wchar_t</span> and C++ library structures
like <code class="classname">wstring</code> were present. This impacted Solaris,
Darwin, and BSD varients, and is fixed in libstdc++ versions post 4.1.0.
</p><p>
</p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.known_bugs"></a>5. Known Bugs</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>5.1. <a href="faq.html#faq.what_works">
What works already?
</a></dt><dt>5.2. <a href="faq.html#faq.standard_bugs">
Bugs in the ISO C++ language or library specification
</a></dt><dt>5.3. <a href="faq.html#faq.compiler_bugs">
Bugs in the compiler (gcc/g++) and not libstdc++
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_works"></a><a id="q-what_works"></a><p><b>5.1.</b></p></td><td align="left" valign="top"><p>
What works already?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_works"></a></td><td align="left" valign="top"><p>
Short answer: Pretty much everything <span class="emphasis"><em>works</em></span>
except for some corner cases. Support for localization
in <code class="classname">locale</code> may be incomplete on non-GNU
platforms. Also dependant on the underlying platform is support
for <span class="type">wchar_t</span> and <span class="type">long
long</span> specializations, and details of thread support.
</p><p>
Long answer: See the implementation status pages for
<a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/c++1998_status.html" target="_top">C++98</a>,
<a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/tr1_status.html" target="_top">TR1</a>, and <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/c++0x_status.html" target="_top">C++0x</a>.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.standard_bugs"></a><a id="q-standard_bugs"></a><p><b>5.2.</b></p></td><td align="left" valign="top"><p>
Bugs in the ISO C++ language or library specification
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-standard_bugs"></a></td><td align="left" valign="top"><p>
Unfortunately, there are some.
</p><p>
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 <a class="ulink" href="http://anubis.dkuug.dk/jtc1/sc22/wg21/" target="_top">here</a>.
Some of these issues have resulted in code changes in libstdc++.
</p><p>
If you think you've discovered a new bug that is not listed,
please post a message describing your problem
to <code class="email">&lt;<a class="email" href="mailto:libstdc++@gcc.gnu.org">libstdc++@gcc.gnu.org</a>&gt;</code> or the Usenet group
comp.lang.c++.moderated.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.compiler_bugs"></a><a id="q-compiler_bugs"></a><p><b>5.3.</b></p></td><td align="left" valign="top"><p>
Bugs in the compiler (gcc/g++) and not libstdc++
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-compiler_bugs"></a></td><td align="left" valign="top"><p>
On occasion, the compiler is wrong. Please be advised that this
happens much less often than one would think, and avoid jumping to
conclusions.
</p><p>
First, examine the ISO C++ standard. Second, try another compiler
or an older version of the GNU compilers. Third, you can find more
information on the libstdc++ and the GCC mailing lists: search
these lists with terms describing your issue.
</p><p>
Before reporting a bug, please examine the
<a class="ulink" href="http://gcc.gnu.org/bugs.html" target="_top">bugs database</a> with the
category set to “<span class="quote">g++</span>”.
</p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.known_non-bugs"></a>6. Known Non-Bugs</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>6.1. <a href="faq.html#faq.stream_reopening_fails">
Reopening a stream fails
</a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose">
-Weffc++ complains too much
</a></dt><dt>6.3. <a href="faq.html#faq.ambiguous_overloads">
Ambiguous overloads after including an old-style header
</a></dt><dt>6.4. <a href="faq.html#faq.v2_headers">
The g++-3 headers are not ours
</a></dt><dt>6.5. <a href="faq.html#faq.boost_concept_checks">
Errors about *Concept and
constraints in the STL
</a></dt><dt>6.6. <a href="faq.html#faq.dlopen_crash">
Program crashes when using library code in a
dynamically-loaded library
</a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">
“Memory leaks” in containers
</a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">
list::size() is O(n)!
</a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
Aw, that's easy to fix!
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.stream_reopening_fails"></a><a id="q-stream_reopening_fails"></a><p><b>6.1.</b></p></td><td align="left" valign="top"><p>
Reopening a stream fails
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-stream_reopening_fails"></a></td><td align="left" valign="top"><p>
One of the most-reported non-bug reports. Executing a sequence like:
</p><div class="literallayout"><p><br />
    #include &lt;fstream&gt;<br />
    ...<br />
    std::fstream  fs(“<span class="quote">a_file</span>”);<br />
    // .<br />
    // . do things with fs...<br />
    // .<br />
    fs.close();<br />
    fs.open(“<span class="quote">a_new_file</span>”);<br />
    </p></div><p>
All operations on the re-opened <code class="varname">fs</code> will fail, or at
least act very strangely. Yes, they often will, especially if
<code class="varname">fs</code> reached the EOF state on the previous file. The
reason is that the state flags are <span class="emphasis"><em>not</em></span> cleared
on a successful call to open(). The standard unfortunately did
not specify behavior in this case, and to everybody's great sorrow,
the <a class="ulink" href="../ext/howto.html#5" target="_top">proposed LWG resolution in
DR #22</a> is to leave the flags unchanged. You must insert a call
to <code class="function">fs.clear()</code> between the calls to close() and open(),
and then everything will work like we all expect it to work.
<span class="emphasis"><em>Update:</em></span> for GCC 4.0 we implemented the resolution
of <a class="ulink" href="../ext/howto.html#5" target="_top">DR #409</a> and open() now calls
<code class="function">clear()</code> on success!
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.wefcxx_verbose"></a><a id="q-wefcxx_verbose"></a><p><b>6.2.</b></p></td><td align="left" valign="top"><p>
-Weffc++ complains too much
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-wefcxx_verbose"></a></td><td align="left" valign="top"><p>
Many warnings are emitted when <code class="literal">-Weffc++</code> is used. Making
libstdc++ <code class="literal">-Weffc++</code>-clean is not a goal of the project,
for a few reasons. Mainly, that option tries to enforce
object-oriented programming, while the Standard Library isn't
necessarily trying to be OO.
</p><p>
We do, however, try to have libstdc++ sources as clean as possible. If
you see some simple changes that pacify <code class="literal">-Weffc++</code>
without other drawbacks, send us a patch.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.ambiguous_overloads"></a><a id="q-ambiguous_overloads"></a><p><b>6.3.</b></p></td><td align="left" valign="top"><p>
Ambiguous overloads after including an old-style header
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-ambiguous_overloads"></a></td><td align="left" valign="top"><p>
Another problem is the <code class="literal">rel_ops</code> namespace and the template
comparison operator functions contained therein. If they become
visible in the same namespace as other comparison functions
(e.g., “<span class="quote">using</span>” them and the &lt;iterator&gt; header),
then you will suddenly be faced with huge numbers of ambiguity
errors. This was discussed on the -v3 list; Nathan Myers
<a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html" target="_top">sums
things up here</a>. The collisions with vector/string iterator
types have been fixed for 3.1.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.v2_headers"></a><a id="q-v2_headers"></a><p><b>6.4.</b></p></td><td align="left" valign="top"><p>
The g++-3 headers are <span class="emphasis"><em>not ours</em></span>
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-v2_headers"></a></td><td align="left" valign="top"><p>
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 <a class="ulink" href="http://gcc.gnu.org/bugs.html" target="_top">the GCC
bug database</a>).
</p><p>
If the headers are in <code class="filename">${prefix}/include/g++-3</code>, or
if the installed library's name looks like
<code class="filename">libstdc++-2.10.a</code> or
<code class="filename">libstdc++-libc6-2.10.so</code>, then you are using the
old libstdc++-v2 library, which is nonstandard and
unmaintained. Do not report problems with -v2 to the -v3
mailing list.
</p><p>
For GCC versions 3.0 and 3.1 the libstdc++ header files are
installed in <code class="filename">${prefix}/include/g++-v3</code> (see the
'v'?). Starting with version 3.2 the headers are installed in
<code class="filename">${prefix}/include/c++/${version}</code> as this prevents
headers from previous versions being found by mistake.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.boost_concept_checks"></a><a id="q-boost_concept_checks"></a><p><b>6.5.</b></p></td><td align="left" valign="top"><p>
Errors about <span class="emphasis"><em>*Concept</em></span> and
<span class="emphasis"><em>constraints</em></span> in the STL
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-boost_concept_checks"></a></td><td align="left" valign="top"><p>
If you see compilation errors containing messages about
<span class="errortext">foo Concept </span>and something to do with a
<span class="errortext">constraints</span> member function, then most
likely you have violated one of the requirements for types used
during instantiation of template containers and functions. For
example, EqualityComparableConcept appears if your types must be
comparable with == and you have not provided this capability (a
typo, or wrong visibility, or you just plain forgot, etc).
</p><p>
More information, including how to optionally enable/disable the
checks, is available
<a class="ulink" href="../19_diagnostics/howto.html#3" target="_top">here</a>.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.dlopen_crash"></a><a id="q-dlopen_crash"></a><p><b>6.6.</b></p></td><td align="left" valign="top"><p>
Program crashes when using library code in a
dynamically-loaded library
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-dlopen_crash"></a></td><td align="left" valign="top"><p>
If you are using the C++ library across dynamically-loaded
objects, make certain that you are passing the correct options
when compiling and linking:
</p><div class="literallayout"><p><br />
    // compile your library components<br />
    g++ -fPIC -c a.cc<br />
    g++ -fPIC -c b.cc<br />
    ...<br />
    g++ -fPIC -c z.cc<br />
<br />
    // create your library<br />
    g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o<br />
<br />
    // link the executable<br />
    g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl<br />
    </p></div></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.memory_leaks"></a><a id="q-memory_leaks"></a><p><b>6.7.</b></p></td><td align="left" valign="top"><p>
“<span class="quote">Memory leaks</span>” in containers
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"></a></td><td align="left" valign="top"><p>
A few people have reported that the standard containers appear
to leak memory when tested with memory checkers such as
<a class="ulink" href="http://developer.kde.org/~sewardj/" target="_top">valgrind</a>.
The library's default allocators keep free memory in a pool
for later reuse, rather than returning it to the OS. Although
this memory is always reachable by the library and is never
lost, memory debugging tools can report it as a leak. If you
want to test the library for memory leaks please read
<a class="ulink" href="../debug.html#mem" target="_top">Tips for memory leak hunting</a>
first.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.list_size_on"></a><a id="q-list_size_on"></a><p><b>6.8.</b></p></td><td align="left" valign="top"><p>
list::size() is O(n)!
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-list_size_on"></a></td><td align="left" valign="top"><p>
See
the <a class="ulink" href="../23_containers/howto.html#6" target="_top">Containers</a>
chapter.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.easy_to_fix"></a><a id="q-easy_to_fix"></a><p><b>6.9.</b></p></td><td align="left" valign="top"><p>
Aw, that's easy to fix!
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-easy_to_fix"></a></td><td align="left" valign="top"><p>
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 <a class="ulink" href="http://gcc.gnu.org/contribute.html" target="_top">submitting
patches</a> 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++
<a class="ulink" href="../17_intro/contribute.html" target="_top">contributors' page</a>
also talks about how to submit patches.
</p><p>
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
<a class="ulink" href="#2_4" target="_top">testsuite</a> -- but only if such a test exists.
</p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.misc"></a>7. Miscellaneous</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>7.1. <a href="faq.html#faq.iterator_as_pod">
string::iterator is not char*; vector&lt;T&gt;::iterator is not T*
</a></dt><dt>7.2. <a href="faq.html#faq.what_is_next">
What's next after libstdc++?
</a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl">
What about the STL from SGI?
</a></dt><dt>7.4. <a href="faq.html#faq.extensions_and_backwards_compat">
Extensions and Backward Compatibility
</a></dt><dt>7.5. <a href="faq.html#faq.tr1_support">
Does libstdc++ support TR1?
</a></dt><dt>7.6. <a href="faq.html#faq.get_iso_cxx">How do I get a copy of the ISO C++ Standard?
</a></dt><dt>7.7. <a href="faq.html#faq.what_is_abi">
What's an ABI and why is it so messy?
</a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity">
How do I make std::vector&lt;T&gt;::capacity() == std::vector&lt;T&gt;::size?
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.iterator_as_pod"></a><a id="faq.iterator_as_pod_q"></a><p><b>7.1.</b></p></td><td align="left" valign="top"><p>
string::iterator is not char*; vector&lt;T&gt;::iterator is not T*
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.iterator_as_pod_a"></a></td><td align="left" valign="top"><p>
If you have code that depends on container&lt;T&gt; iterators
being implemented as pointer-to-T, your code is broken. It's
considered a feature, not a bug, that libstdc++ points this out.
</p><p>
While there are arguments for iterators to be implemented in
that manner, A) they aren't very good ones in the long term,
and B) they were never guaranteed by the Standard anyway. The
type-safety achieved by making iterators a real class rather
than a typedef for <span class="type">T*</span> outweighs nearly all opposing
arguments.
</p><p>
Code which does assume that a vector iterator <code class="varname">i</code>
is a pointer can often be fixed by changing <code class="varname">i</code> in
certain expressions to <code class="varname">&amp;*i</code>. Future revisions
of the Standard are expected to bless this usage for
vector&lt;&gt; (but not for basic_string&lt;&gt;).
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_next"></a><a id="q-what_is_next"></a><p><b>7.2.</b></p></td><td align="left" valign="top"><p>
What's next after libstdc++?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_next"></a></td><td align="left" valign="top"><p>
Hopefully, not much. The goal of libstdc++ is to produce a
fully-compliant, fully-portable Standard Library. After that,
we're mostly done: there won't <span class="emphasis"><em>be</em></span> any
more compliance work to do.
</p><p>
There is an effort underway to add significant extensions to
the standard library specification. The latest version of
this effort is described in
<a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf" target="_top">
The C++ Library Technical Report 1</a>.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.sgi_stl"></a><a id="q-sgi_stl"></a><p><b>7.3.</b></p></td><td align="left" valign="top"><p>
What about the STL from SGI?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-sgi_stl"></a></td><td align="left" valign="top"><p>
The <a class="ulink" href="http://www.sgi.com/tech/stl/" target="_top">STL from SGI</a>,
version 3.3, was the final merge of the STL codebase. The
code in libstdc++ contains many fixes and changes, and
the SGI code is no longer under active
development. We expect that no future merges will take place.
</p><p>
In particular, <code class="classname">string</code> is not from SGI and makes no
use of their "rope" class (which is included as an
optional extension), nor is <code class="classname">valarray</code> and some others.
Classes like <code class="classname">vector&lt;&gt;</code> are, but have been
extensively modified.
</p><p>
More information on the evolution of libstdc++ can be found at the
<a class="link" href="manual/api.html" title="API Evolution and Deprecation History">API
evolution</a>
and <a class="link" href="manual/backwards.html" title="Backwards Compatibility">backwards
compatibility</a> documentation.
</p><p>
The FAQ for SGI's STL (one jump off of their main page) is
still recommended reading.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.extensions_and_backwards_compat"></a><a id="q-extensions_and_backwards_compat"></a><p><b>7.4.</b></p></td><td align="left" valign="top"><p>
Extensions and Backward Compatibility
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-extensions_and_backwards_compat"></a></td><td align="left" valign="top"><p>
See the <a class="link" href="manual/backwards.html" title="Backwards Compatibility">link</a> on backwards compatiblity and <a class="link" href="manual/api.html" title="API Evolution and Deprecation History">link</a> on evolution.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.tr1_support"></a><a id="q-tr1_support"></a><p><b>7.5.</b></p></td><td align="left" valign="top"><p>
Does libstdc++ support TR1?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-tr1_support"></a></td><td align="left" valign="top"><p>
Yes.
</p><p>
The C++ Standard Library Technical Report adds many new features to
the library. The latest version of this effort is described in
<a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf" target="_top">
Technical Report 1</a>.
</p><p>
The implementation status of TR1 in libstdc++ can be tracked <a class="link" href="manual/bk01pt01ch01.html#manual.intro.status.standard.tr1" title="C++ TR1">on the TR1 status
page</a>.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.get_iso_cxx"></a><a id="q-get_iso_cxx"></a><p><b>7.6.</b></p></td><td align="left" valign="top"><p>How do I get a copy of the ISO C++ Standard?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-get_iso_cxx"></a></td><td align="left" valign="top"><p>
Copies of the full ISO 14882 standard are available on line via
the ISO mirror site for committee members. Non-members, or those
who have not paid for the privilege of sitting on the committee
and sustained 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 <a class="ulink" href="http://www.ansi.org" target="_top">here</a>. (And if
you've already registered with them, clicking this link will take
you to directly to the place where you can
<a class="ulink" href="http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%3A2003" target="_top">buy the standard on-line</a>.
</p><p>
Who is your country's member body? Visit the
<a class="ulink" href="http://www.iso.ch/" target="_top">ISO homepage</a> and find out!
</p><p>
The 2003 version of the standard (the 1998 version plus TC1) is
available in print, ISBN 0-470-84674-7.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_abi"></a><a id="q-what_is_abi"></a><p><b>7.7.</b></p></td><td align="left" valign="top"><p>
What's an ABI and why is it so messy?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_abi"></a></td><td align="left" valign="top"><p>
<acronym class="acronym">ABI</acronym> stands for “<span class="quote">Application Binary
Interface</span>”. Conventionally, it refers to a great
mass of details about how arguments are arranged on the call
stack and/or in registers, and how various types are arranged
and padded in structs. A single CPU design may suffer
multiple ABIs designed by different development tool vendors
who made different choices, or even by the same vendor for
different target applications or compiler versions. In ideal
circumstances the CPU designer presents one ABI and all the
OSes and compilers use it. In practice every ABI omits
details that compiler implementers (consciously or
accidentally) must choose for themselves.
</p><p>
That ABI definition suffices for compilers to generate code so a
program can interact safely with an OS and its lowest-level libraries.
Users usually want an ABI to encompass more detail, allowing libraries
built with different compilers (or different releases of the same
compiler!) to be linked together. For C++, this includes many more
details than for C, and CPU designers (for good reasons elaborated
below) have not stepped up to publish C++ ABIs. The details include
virtual function implementation, struct inheritance layout, name
mangling, and exception handling. Such an ABI has been defined for
GNU C++, and is immediately useful for embedded work relying only on
a “<span class="quote">free-standing implementation</span>” that doesn't include (much
of) the standard library. It is a good basis for the work to come.
</p><p>
A useful C++ ABI must also incorporate many details of the standard
library implementation. For a C ABI, the layouts of a few structs
(such as FILE, stat, jmpbuf, and the like) and a few macros suffice.
For C++, the details include the complete set of names of functions
and types used, the offsets of class members and virtual functions,
and the actual definitions of all inlines. C++ exposes many more
library details to the caller than C does. It makes defining
a complete ABI a much bigger undertaking, and requires not just
documenting library implementation details, but carefully designing
those details so that future bug fixes and optimizations don't
force breaking the ABI.
</p><p>
There are ways to help isolate library implementation details from the
ABI, but they trade off against speed. Library details used in
inner loops (e.g., getchar) must be exposed and frozen for all
time, but many others may reasonably be kept hidden from user code,
so they may later be changed. Deciding which, and implementing
the decisions, must happen before you can reasonably document a
candidate C++ ABI that encompasses the standard library.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.size_equals_capacity"></a><a id="q-size_equals_capacity"></a><p><b>7.8.</b></p></td><td align="left" valign="top"><p>
How do I make std::vector&lt;T&gt;::capacity() == std::vector&lt;T&gt;::size?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size_equals_capacity"></a></td><td align="left" valign="top"><p>
The standard idiom for deallocating a <code class="classname">vector&lt;T&gt;</code>'s
unused memory is to create a temporary copy of the vector and swap their
contents, e.g. for <code class="classname">vector&lt;T&gt; v</code>
</p><div class="literallayout"><p><br />
     std::vector&lt;T&gt;(v).swap(v);<br />
    </p></div><p>
The copy will take O(n) time and the swap is constant time.
</p><p>
See <a class="ulink" href="../21_strings/howto.html#6" target="_top">Shrink-to-fit
strings</a> for a similar solution for strings.
</p></td></tr></tbody></table></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk03.html">Up</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="spine.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>

493
libstdc++-v3/doc/html/manual/abi.html Normal file
View File

@ -0,0 +1,493 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>ABI Policy and Guidelines</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; C++&#10; , &#10; ABI&#10; , &#10; version&#10; , &#10; dynamic&#10; , &#10; shared&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_porting.html" title="Appendix B. Porting and Maintenance" /><link rel="prev" href="internals.html" title="Porting to New Hardware or Operating Systems" /><link rel="next" href="api.html" title="API Evolution and Deprecation History" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">ABI Policy and Guidelines</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="internals.html">Prev</a> </td><th width="60%" align="center">Appendix B. Porting and Maintenance</th><td width="20%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="appendix.porting.abi"></a>ABI Policy and Guidelines</h2></div></div></div><p>
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.cxx_interface"></a>The C++ Interface</h3></div></div></div><p>
C++ applications often dependent on specific language support
routines, say for throwing exceptions, or catching exceptions, and
perhaps also dependent on features in the C++ Standard Library.
</p><p>
The C++ Standard Library has many include files, types defined in
those include files, specific named functions, and other
behavior. The text of these behaviors, as written in source include
files, is called the Application Programing Interface, or API.
</p><p>
Furthermore, C++ source that is compiled into object files is
transformed by the compiler: it arranges objects with specific
alignment and in a particular layout, mangling names according to a
well-defined algorithm, has specific arrangements for the support of
virtual functions, etc. These details are defined as the compiler
Application Binary Interface, or ABI. The GNU C++ compiler uses an
industry-standard C++ ABI starting with version 3. Details can be
found in the <a class="ulink" href="http://www.codesourcery.com/cxx-abi/abi.html" target="_top"> ABI
specification</a>.
</p><p>
The GNU C++ compiler, g++, has a compiler command line option to
switch between various different C++ ABIs. This explicit version
switch is the flag <code class="code">-fabi-version</code>. In addition, some
g++ command line options may change the ABI as a side-effect of
use. Such flags include <code class="code">-fpack-struct</code> and
<code class="code">-fno-exceptions</code>, but include others: see the complete
list in the GCC manual under the heading <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code%20Gen%20Options" target="_top">Options
for Code Generation Conventions</a>.
</p><p>
The configure options used when building a specific libstdc++
version may also impact the resulting library ABI. The available
configure options, and their impact on the library ABI, are
documented
<a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html" target="_top">
here</a>.
</p><p> Putting all of these ideas together results in the C++ Standard
library ABI, which is the compilation of a given library API by a
given compiler ABI. In a nutshell:
</p><p>
“<span class="quote">
library API + compiler ABI = library ABI
</span>”
</p><p>
The library ABI is mostly of interest for end-users who have
unresolved symbols and are linking dynamically to the C++ Standard
library, and who thus must be careful to compile their application
with a compiler that is compatible with the available C++ Standard
library binary. In this case, compatible is defined with the equation
above: given an application compiled with a given compiler ABI and
library API, it will work correctly with a Standard C++ Library
created with the same constraints.
</p><p>
To use a specific version of the C++ ABI, one must use a
corresponding GNU C++ toolchain (Ie, g++ and libstdc++) that
implements the C++ ABI in question.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.versioning"></a>Versioning</h3></div></div></div><p> The C++ interface has evolved throughout the history of the GNU
C++ toolchain. With each release, various details have been changed so
as to give distinct versions to the C++ interface.
</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.goals"></a>Goals</h4></div></div></div><p>Extending existing, stable ABIs. Versioning gives subsequent stable
releases series libraries the ability to add new symbols and add
functionality, all the while retaining backwards compatibility with
the previous releases in the series. Note: the reverse is not true. It
is not possible to take binaries linked with the latest version of a
release series (if symbols have been added) and expect the initial
release of the series to remain link compatible.
</p><p>Allows multiple, incompatible ABIs to coexist at the same time.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.history"></a>History</h4></div></div></div><p>
How can this complexity be managed? What does C++ versioning mean?
Because library and compiler changes often make binaries compiled
with one version of the GNU tools incompatible with binaries
compiled with other (either newer or older) versions of the same GNU
tools, specific techniques are used to make managing this complexity
easier.
</p><p>
The following techniques are used:
</p><div class="orderedlist"><ol type="1"><li><p>Release versioning on the libgcc_s.so binary. </p><p>This is implemented via file names and the ELF DT_SONAME
mechanism (at least on ELF systems). It is versioned as follows:
</p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: libgcc_s.so.1</p></li><li><p>gcc-3.0.1: libgcc_s.so.1</p></li><li><p>gcc-3.0.2: libgcc_s.so.1</p></li><li><p>gcc-3.0.3: libgcc_s.so.1</p></li><li><p>gcc-3.0.4: libgcc_s.so.1</p></li><li><p>gcc-3.1.0: libgcc_s.so.1</p></li><li><p>gcc-3.1.1: libgcc_s.so.1</p></li><li><p>gcc-3.2.0: libgcc_s.so.1</p></li><li><p>gcc-3.2.1: libgcc_s.so.1</p></li><li><p>gcc-3.2.2: libgcc_s.so.1</p></li><li><p>gcc-3.2.3: libgcc_s.so.1</p></li><li><p>gcc-3.3.0: libgcc_s.so.1</p></li><li><p>gcc-3.3.1: libgcc_s.so.1</p></li><li><p>gcc-3.3.2: libgcc_s.so.1</p></li><li><p>gcc-3.3.3: libgcc_s.so.1</p></li><li><p>gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: on m68k-linux and
hppa-linux this is either libgcc_s.so.1 (when configuring
<code class="code">--with-sjlj-exceptions</code>) or libgcc_s.so.2. For all
others, this is libgcc_s.so.1. </p></li></ul></div></li><li><p>Symbol versioning on the libgcc_s.so binary.</p><p>It is versioned with the following labels and version
definitions, where the version definition is the maximum for a
particular release. Labels are cumulative. If a particular release
is not listed, it has the same version labels as the preceeding
release.</p><p>This corresponds to the mapfile: gcc/libgcc-std.ver</p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: GCC_3.0</p></li><li><p>gcc-3.3.0: GCC_3.3</p></li><li><p>gcc-3.3.1: GCC_3.3.1</p></li><li><p>gcc-3.3.2: GCC_3.3.2</p></li><li><p>gcc-3.3.4: GCC_3.3.4</p></li><li><p>gcc-3.4.0: GCC_3.4</p></li><li><p>gcc-3.4.2: GCC_3.4.2</p></li><li><p>gcc-3.4.4: GCC_3.4.4</p></li><li><p>gcc-4.0.0: GCC_4.0.0</p></li><li><p>gcc-4.1.0: GCC_4.1.0</p></li><li><p>gcc-4.2.0: GCC_4.2.0</p></li></ul></div></li><li><p>Release versioning on the libstdc++.so binary, implemented in the same was as the libgcc_s.so binary, above.</p><p>It is versioned as follows:
</p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: libstdc++.so.3.0.0</p></li><li><p>gcc-3.0.1: libstdc++.so.3.0.1</p></li><li><p>gcc-3.0.2: libstdc++.so.3.0.2</p></li><li><p>gcc-3.0.3: libstdc++.so.3.0.2 (Error should be libstdc++.so.3.0.3)</p></li><li><p>gcc-3.0.4: libstdc++.so.3.0.4</p></li><li><p>gcc-3.1.0: libstdc++.so.4.0.0</p></li><li><p>gcc-3.1.1: libstdc++.so.4.0.1</p></li><li><p>gcc-3.2.0: libstdc++.so.5.0.0</p></li><li><p>gcc-3.2.1: libstdc++.so.5.0.1</p></li><li><p>gcc-3.2.2: libstdc++.so.5.0.2</p></li><li><p>gcc-3.2.3: libstdc++.so.5.0.3 (Not strictly required)</p></li><li><p>gcc-3.3.0: libstdc++.so.5.0.4</p></li><li><p>gcc-3.3.1: libstdc++.so.5.0.5</p></li><li><p>gcc-3.3.2: libstdc++.so.5.0.5</p></li><li><p>gcc-3.3.3: libstdc++.so.5.0.5</p></li><li><p>gcc-3.4.0: libstdc++.so.6.0.0</p></li><li><p>gcc-3.4.1: libstdc++.so.6.0.1</p></li><li><p>gcc-3.4.2: libstdc++.so.6.0.2</p></li><li><p>gcc-3.4.3: libstdc++.so.6.0.3</p></li><li><p>gcc-3.4.4: libstdc++.so.6.0.3</p></li><li><p>gcc-3.4.5: libstdc++.so.6.0.3</p></li><li><p>gcc-3.4.6: libstdc++.so.6.0.3</p></li><li><p>gcc-4.0.0: libstdc++.so.6.0.4</p></li><li><p>gcc-4.0.1: libstdc++.so.6.0.5</p></li><li><p>gcc-4.0.2: libstdc++.so.6.0.6</p></li><li><p>gcc-4.0.3: libstdc++.so.6.0.7</p></li><li><p>gcc-4.1.0: libstdc++.so.6.0.7</p></li><li><p>gcc-4.1.1: libstdc++.so.6.0.8</p></li><li><p>gcc-4.1.2: libstdc++.so.6.0.8</p></li><li><p>gcc-4.2.0: libstdc++.so.6.0.9</p></li></ul></div></li><li><p>Symbol versioning on the libstdc++.so binary.</p><p>mapfile: libstdc++/config/linker-map.gnu</p><p>It is versioned with the following labels and version
definitions, where the version definition is the maximum for a
particular release. Note, only symbol which are newly introduced
will use the maximum version definition. Thus, for release series
with the same label, but incremented version definitions, the later
release has both versions. (An example of this would be the
gcc-3.2.1 release, which has GLIBCPP_3.2.1 for new symbols and
GLIBCPP_3.2 for symbols that were introduced in the gcc-3.2.0
release.) If a particular release is not listed, it has the same
version labels as the preceeding release.
</p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: (Error, not versioned)</p></li><li><p>gcc-3.0.1: (Error, not versioned)</p></li><li><p>gcc-3.0.2: (Error, not versioned)</p></li><li><p>gcc-3.0.3: (Error, not versioned)</p></li><li><p>gcc-3.0.4: (Error, not versioned)</p></li><li><p>gcc-3.1.0: GLIBCPP_3.1, CXXABI_1</p></li><li><p>gcc-3.1.1: GLIBCPP_3.1, CXXABI_1</p></li><li><p>gcc-3.2.0: GLIBCPP_3.2, CXXABI_1.2</p></li><li><p>gcc-3.2.1: GLIBCPP_3.2.1, CXXABI_1.2</p></li><li><p>gcc-3.2.2: GLIBCPP_3.2.2, CXXABI_1.2</p></li><li><p>gcc-3.2.3: GLIBCPP_3.2.2, CXXABI_1.2</p></li><li><p>gcc-3.3.0: GLIBCPP_3.2.2, CXXABI_1.2.1</p></li><li><p>gcc-3.3.1: GLIBCPP_3.2.3, CXXABI_1.2.1</p></li><li><p>gcc-3.3.2: GLIBCPP_3.2.3, CXXABI_1.2.1</p></li><li><p>gcc-3.3.3: GLIBCPP_3.2.3, CXXABI_1.2.1</p></li><li><p>gcc-3.4.0: GLIBCXX_3.4, CXXABI_1.3</p></li><li><p>gcc-3.4.1: GLIBCXX_3.4.1, CXXABI_1.3</p></li><li><p>gcc-3.4.2: GLIBCXX_3.4.2</p></li><li><p>gcc-3.4.3: GLIBCXX_3.4.3</p></li><li><p>gcc-4.0.0: GLIBCXX_3.4.4, CXXABI_1.3.1</p></li><li><p>gcc-4.0.1: GLIBCXX_3.4.5</p></li><li><p>gcc-4.0.2: GLIBCXX_3.4.6</p></li><li><p>gcc-4.0.3: GLIBCXX_3.4.7</p></li><li><p>gcc-4.1.1: GLIBCXX_3.4.8</p></li><li><p>gcc-4.2.0: GLIBCXX_3.4.9</p></li></ul></div></li><li><p>Incremental bumping of a compiler pre-defined macro,
__GXX_ABI_VERSION. This macro is defined as the version of the
compiler v3 ABI, with g++ 3.0.x being version 100. This macro will
be automatically defined whenever g++ is used (the curious can
test this by invoking g++ with the '-v' flag.)
</p><p>
This macro was defined in the file "lang-specs.h" in the gcc/cp directory.
Later versions defined it in "c-common.c" in the gcc directory, and from
G++ 3.4 it is defined in c-cppbuiltin.c and its value determined by the
'-fabi-version' command line option.
</p><p>
It is versioned as follows, where 'n' is given by '-fabi-version=n':
</p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.x: 100</p></li><li><p>gcc-3.1.x: 100 (Error, should be 101)</p></li><li><p>gcc-3.2.x: 102</p></li><li><p>gcc-3.3.x: 102</p></li><li><p>gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: 102 (when n=1)</p></li><li><p>gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: 1000 + n (when n&gt;1)</p></li><li><p>gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: 999999 (when n=0)</p></li></ul></div><p></p></li><li><p>Changes to the default compiler option for
<code class="code">-fabi-version</code>.
</p><p>
It is versioned as follows:
</p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.x: (Error, not versioned) </p></li><li><p>gcc-3.1.x: (Error, not versioned) </p></li><li><p>gcc-3.2.x: <code class="code">-fabi-version=1</code></p></li><li><p>gcc-3.3.x: <code class="code">-fabi-version=1</code></p></li><li><p>gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: <code class="code">-fabi-version=2</code></p></li></ul></div><p></p></li><li><p>Incremental bumping of a library pre-defined macro. For releases
before 3.4.0, the macro is __GLIBCPP__. For later releases, it's
__GLIBCXX__. (The libstdc++ project generously changed from CPP to
CXX throughout its source to allow the "C" pre-processor the CPP
macro namespace.) These macros are defined as the date the library
was released, in compressed ISO date format, as an unsigned long.
</p><p>
This macro is defined in the file "c++config" in the
"libstdc++/include/bits" directory. (Up to gcc-4.1.0, it was
changed every night by an automated script. Since gcc-4.1.0, it is
the same value as gcc/DATESTAMP.)
</p><p>
It is versioned as follows:
</p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: 20010615</p></li><li><p>gcc-3.0.1: 20010819</p></li><li><p>gcc-3.0.2: 20011023</p></li><li><p>gcc-3.0.3: 20011220</p></li><li><p>gcc-3.0.4: 20020220</p></li><li><p>gcc-3.1.0: 20020514</p></li><li><p>gcc-3.1.1: 20020725</p></li><li><p>gcc-3.2.0: 20020814</p></li><li><p>gcc-3.2.1: 20021119</p></li><li><p>gcc-3.2.2: 20030205</p></li><li><p>gcc-3.2.3: 20030422</p></li><li><p>gcc-3.3.0: 20030513</p></li><li><p>gcc-3.3.1: 20030804</p></li><li><p>gcc-3.3.2: 20031016</p></li><li><p>gcc-3.3.3: 20040214</p></li><li><p>gcc-3.4.0: 20040419</p></li><li><p>gcc-3.4.1: 20040701</p></li><li><p>gcc-3.4.2: 20040906</p></li><li><p>gcc-3.4.3: 20041105</p></li><li><p>gcc-3.4.4: 20050519</p></li><li><p>gcc-3.4.5: 20051201</p></li><li><p>gcc-3.4.6: 20060306</p></li><li><p>gcc-4.0.0: 20050421</p></li><li><p>gcc-4.0.1: 20050707</p></li><li><p>gcc-4.0.2: 20050921</p></li><li><p>gcc-4.0.3: 20060309</p></li><li><p>gcc-4.1.0: 20060228</p></li><li><p>gcc-4.1.1: 20060524</p></li><li><p>gcc-4.1.2: 20070214</p></li><li><p>gcc-4.2.0: 20070514</p></li></ul></div><p></p></li><li><p>
Incremental bumping of a library pre-defined macro,
_GLIBCPP_VERSION. This macro is defined as the released version of
the library, as a string literal. This is only implemented in
gcc-3.1.0 releases and higher, and is deprecated in 3.4 (where it
is called _GLIBCXX_VERSION).
</p><p>
This macro is defined in the file "c++config" in the
"libstdc++/include/bits" directory and is generated
automatically by autoconf as part of the configure-time generation
of config.h.
</p><p>
It is versioned as follows:
</p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: "3.0.0"</p></li><li><p>gcc-3.0.1: "3.0.0" (Error, should be "3.0.1")</p></li><li><p>gcc-3.0.2: "3.0.0" (Error, should be "3.0.2")</p></li><li><p>gcc-3.0.3: "3.0.0" (Error, should be "3.0.3")</p></li><li><p>gcc-3.0.4: "3.0.0" (Error, should be "3.0.4")</p></li><li><p>gcc-3.1.0: "3.1.0"</p></li><li><p>gcc-3.1.1: "3.1.1"</p></li><li><p>gcc-3.2.0: "3.2"</p></li><li><p>gcc-3.2.1: "3.2.1"</p></li><li><p>gcc-3.2.2: "3.2.2"</p></li><li><p>gcc-3.2.3: "3.2.3"</p></li><li><p>gcc-3.3.0: "3.3"</p></li><li><p>gcc-3.3.1: "3.3.1"</p></li><li><p>gcc-3.3.2: "3.3.2"</p></li><li><p>gcc-3.3.3: "3.3.3"</p></li><li><p>gcc-3.4.x: "version-unused"</p></li><li><p>gcc-4.0.x: "version-unused"</p></li><li><p>gcc-4.1.x: "version-unused"</p></li><li><p>gcc-4.2.x: "version-unused"</p></li></ul></div><p></p></li><li><p>
Matching each specific C++ compiler release to a specific set of
C++ include files. This is only implemented in gcc-3.1.1 releases
and higher.
</p><p>
All C++ includes are installed in include/c++, then nest in a
directory hierarchy corresponding to the C++ compiler's released
version. This version corresponds to the variable "gcc_version" in
"libstdc++/acinclude.m4," and more details can be found in that
file's macro GLIBCXX_CONFIGURE (GLIBCPP_CONFIGURE before gcc-3.4.0).
</p><p>
C++ includes are versioned as follows:
</p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: include/g++-v3</p></li><li><p>gcc-3.0.1: include/g++-v3</p></li><li><p>gcc-3.0.2: include/g++-v3</p></li><li><p>gcc-3.0.3: include/g++-v3</p></li><li><p>gcc-3.0.4: include/g++-v3</p></li><li><p>gcc-3.1.0: include/g++-v3</p></li><li><p>gcc-3.1.1: include/c++/3.1.1</p></li><li><p>gcc-3.2.0: include/c++/3.2</p></li><li><p>gcc-3.2.1: include/c++/3.2.1</p></li><li><p>gcc-3.2.2: include/c++/3.2.2</p></li><li><p>gcc-3.2.3: include/c++/3.2.3</p></li><li><p>gcc-3.3.0: include/c++/3.3</p></li><li><p>gcc-3.3.1: include/c++/3.3.1</p></li><li><p>gcc-3.3.2: include/c++/3.3.2</p></li><li><p>gcc-3.3.3: include/c++/3.3.3</p></li><li><p>gcc-3.4.0: include/c++/3.4.0</p></li><li><p>gcc-3.4.1: include/c++/3.4.1</p></li><li><p>gcc-3.4.2: include/c++/3.4.2</p></li><li><p>gcc-3.4.3: include/c++/3.4.3</p></li><li><p>gcc-3.4.4: include/c++/3.4.4</p></li><li><p>gcc-3.4.5: include/c++/3.4.5</p></li><li><p>gcc-3.4.6: include/c++/3.4.6</p></li><li><p>gcc-4.0.0: include/c++/4.0.0</p></li><li><p>gcc-4.0.1: include/c++/4.0.1</p></li><li><p>gcc-4.0.2: include/c++/4.0.2</p></li><li><p>gcc-4.0.3: include/c++/4.0.3</p></li><li><p>gcc-4.1.0: include/c++/4.1.0</p></li><li><p>gcc-4.1.1: include/c++/4.1.1</p></li><li><p>gcc-4.1.2: include/c++/4.1.2</p></li><li><p>gcc-4.2.0: include/c++/4.2.0</p></li></ul></div><p></p></li></ol></div><p>
Taken together, these techniques can accurately specify interface
and implementation changes in the GNU C++ tools themselves. Used
properly, they allow both the GNU C++ tools implementation, and
programs using them, an evolving yet controlled development that
maintains backward compatibility.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.prereq"></a>Prerequisites</h4></div></div></div><p>
Minimum environment that supports a versioned ABI: A supported
dynamic linker, a GNU linker of sufficient vintage to understand
demangled C++ name globbing (ld), a shared executable compiled
with g++, and shared libraries (libgcc_s, libstdc++) compiled by
a compiler (g++) with a compatible ABI. Phew.
</p><p>
On top of all that, an additional constraint: libstdc++ did not
attempt to version symbols (or age gracefully, really) until
version 3.1.0.
</p><p>
Most modern Linux and BSD versions, particularly ones using
gcc-3.1.x tools and more recent vintages, will meet the
requirements above.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.config"></a>Configuring</h4></div></div></div><p>
It turns out that most of the configure options that change
default behavior will impact the mangled names of exported
symbols, and thus impact versioning and compatibility.
</p><p>
For more information on configure options, including ABI
impacts, see:
http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html
</p><p>
There is one flag that explicitly deals with symbol versioning:
--enable-symvers.
</p><p>
In particular, libstdc++/acinclude.m4 has a macro called
GLIBCXX_ENABLE_SYMVERS that defaults to yes (or the argument
passed in via --enable-symvers=foo). At that point, the macro
attempts to make sure that all the requirement for symbol
versioning are in place. For more information, please consult
acinclude.m4.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.active"></a>Checking Active</h4></div></div></div><p>
When the GNU C++ library is being built with symbol versioning
on, you should see the following at configure time for
libstdc++:
</p><pre class="screen">
<code class="computeroutput">
checking versioning on shared library symbols... gnu
</code>
</pre><p>
If you don't see this line in the configure output, or if this line
appears but the last word is 'no', then you are out of luck.
</p><p>
If the compiler is pre-installed, a quick way to test is to compile
the following (or any) simple C++ file and link it to the shared
libstdc++ library:
</p><pre class="programlisting">
#include &lt;iostream&gt;
int main()
{ std::cout &lt;&lt; "hello" &lt;&lt; std::endl; return 0; }
%g++ hello.cc -o hello.out
%ldd hello.out
libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x00764000)
libm.so.6 =&gt; /lib/tls/libm.so.6 (0x004a8000)
libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40016000)
libc.so.6 =&gt; /lib/tls/libc.so.6 (0x0036d000)
/lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
%nm hello.out
</pre><p>
If you see symbols in the resulting output with "GLIBCXX_3" as part
of the name, then the executable is versioned. Here's an example:
</p><p>
<code class="code">U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4</code>
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.changes_allowed"></a>Allowed Changes</h3></div></div></div><p>
The following will cause the library minor version number to
increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.3.0.5".
</p><div class="orderedlist"><ol type="1"><li><p>Adding an exported global or static data member</p></li><li><p>Adding an exported function, static or non-virtual member function</p></li><li><p>Adding an exported symbol or symbols by additional instantiations</p></li></ol></div><p>
Other allowed changes are possible.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.changes_no"></a>Prohibited Changes</h3></div></div></div><p>
The following non-exhaustive list will cause the library major version
number to increase, say from "libstdc++.so.3.0.4" to
"libstdc++.so.4.0.0".
</p><div class="orderedlist"><ol type="1"><li><p>Changes in the gcc/g++ compiler ABI</p></li><li><p>Changing size of an exported symbol</p></li><li><p>Changing alignment of an exported symbol</p></li><li><p>Changing the layout of an exported symbol</p></li><li><p>Changing mangling on an exported symbol</p></li><li><p>Deleting an exported symbol</p></li><li><p>Changing the inheritance properties of a type by adding or removing
base classes</p></li><li><p>
Changing the size, alignment, or layout of types
specified in the C++ standard. These may not necessarily be
instantiated or otherwise exported in the library binary, and
include all the required locale facets, as well as things like
std::basic_streambuf, et al.
</p></li><li><p> Adding an explicit copy constructor or destructor to a
class that would otherwise have implicit versions. This will change
the way the compiler deals with this class in by-value return
statements or parameters: instead of being passing instances of this
class in registers, the compiler will be forced to use memory. See <a class="ulink" href="http://www.codesourcery.com/cxx-abi/abi.html#calls" target="_top"> this part</a>
of the C++ ABI documentation for further details.
</p></li></ol></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.impl"></a>Implementation</h3></div></div></div><div class="orderedlist"><ol type="1"><li><p>
Separation of interface and implementation
</p><p>
This is accomplished by two techniques that separate the API from
the ABI: forcing undefined references to link against a library
binary for definitions.
</p><div class="variablelist"><dl><dt><span class="term">Include files have declarations, source files have defines</span></dt><dd><p>
For non-templatized types, such as much of <code class="code">class
locale</code>, the appropriate standard C++ include, say
<code class="code">locale</code>, can contain full declarations, while
various source files (say <code class="code"> locale.cc, locale_init.cc,
localename.cc</code>) contain definitions.
</p></dd><dt><span class="term">Extern template on required types</span></dt><dd><p>
For parts of the standard that have an explicit list of
required instantiations, the GNU extension syntax <code class="code"> extern
template </code> can be used to control where template
definitions reside. By marking required instantiations as
<code class="code"> extern template </code> in include files, and providing
explicit instantiations in the appropriate instantiation files,
non-inlined template functions can be versioned. This technique
is mostly used on parts of the standard that require <code class="code">
char</code> and <code class="code"> wchar_t</code> instantiations, and
includes <code class="code"> basic_string</code>, the locale facets, and the
types in <code class="code"> iostreams</code>.
</p></dd></dl></div><p>
In addition, these techniques have the additional benefit that they
reduce binary size, which can increase runtime performance.
</p></li><li><p>
Namespaces linking symbol definitions to export mapfiles
</p><p>
All symbols in the shared library binary are processed by a
linker script at build time that either allows or disallows
external linkage. Because of this, some symbols, regardless of
normal C/C++ linkage, are not visible. Symbols that are internal
have several appealing characteristics: by not exporting the
symbols, there are no relocations when the shared library is
started and thus this makes for faster runtime loading
performance by the underlying dynamic loading mechanism. In
addition, they have the possibility of changing without impacting
ABI compatibility.
</p><p>The following namespaces are transformed by the mapfile:</p><div class="variablelist"><dl><dt><span class="term"><code class="code">namespace std</code></span></dt><dd><p> Defaults to exporting all symbols in label
<code class="code">GLIBCXX</code> that do not begin with an underscore, ie
<code class="code">__test_func</code> would not be exported by default. Select
exceptional symbols are allowed to be visible.</p></dd><dt><span class="term"><code class="code">namespace __gnu_cxx</code></span></dt><dd><p> Defaults to not exporting any symbols in label
<code class="code">GLIBCXX</code>, select items are allowed to be visible.</p></dd><dt><span class="term"><code class="code">namespace __gnu_internal</code></span></dt><dd><p> Defaults to not exported, no items are allowed to be visible.</p></dd><dt><span class="term"><code class="code">namespace __cxxabiv1</code>, aliased to <code class="code"> namespace abi</code></span></dt><dd><p> Defaults to not exporting any symbols in label
<code class="code">CXXABI</code>, select items are allowed to be visible.</p></dd></dl></div><p>
</p></li><li><p>Freezing the API</p><p>Disallowed changes, as above, are not made on a stable release
branch. Enforcement tends to be less strict with GNU extensions that
standard includes.</p></li></ol></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.testing"></a>Testing</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.testing.single"></a>Single ABI Testing</h4></div></div></div><p>
Testing for GNU C++ ABI changes is composed of two distinct
areas: testing the C++ compiler (g++) for compiler changes, and
testing the C++ library (libstdc++) for library changes.
</p><p>
Testing the C++ compiler ABI can be done various ways.
</p><p>
One. Intel ABI checker. More information can be obtained <a class="ulink" href="http://developer.intel.com/software/products/opensource/" target="_top">here.</a>
</p><p>
Two.
The second is yet unreleased, but has been announced on the gcc
mailing list. It is yet unspecified if these tools will be freely
available, and able to be included in a GNU project. Please contact
Mark Mitchell (mark@codesourcery.com) for more details, and current
status.
</p><p>
Three.
Involves using the vlad.consistency test framework. This has also been
discussed on the gcc mailing lists.
</p><p>
Testing the C++ library ABI can also be done various ways.
</p><p>
One.
(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways,
one with a new compiler and an old library, and the other with an old
compiler and a new library, and look for testsuite regressions)
</p><p>
Details on how to set this kind of test up can be found here:
http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html
</p><p>
Two.
Use the 'make check-abi' rule in the libstdc++ Makefile.
</p><p>
This is a proactive check the library ABI. Currently, exported symbol
names that are either weak or defined are checked against a last known
good baseline. Currently, this baseline is keyed off of 3.4.0
binaries, as this was the last time the .so number was incremented. In
addition, all exported names are demangled, and the exported objects
are checked to make sure they are the same size as the same object in
the baseline.
Notice that each baseline is relative to a <span class="emphasis"><em>default</em></span>
configured library and compiler: in particular, if options such as
--enable-clocale, or --with-cpu, in case of multilibs, are used at
configure time, the check may fail, either because of substantive
differences or because of limitations of the current checking
machinery.
</p><p>
This dataset is insufficient, yet a start. Also needed is a
comprehensive check for all user-visible types part of the standard
library for sizeof() and alignof() changes.
</p><p>
Verifying compatible layouts of objects is not even attempted. It
should be possible to use sizeof, alignof, and offsetof to compute
offsets for each structure and type in the standard library, saving to
another datafile. Then, compute this in a similar way for new
binaries, and look for differences.
</p><p>
Another approach might be to use the -fdump-class-hierarchy flag to
get information. However, currently this approach gives insufficient
data for use in library testing, as class data members, their offsets,
and other detailed data is not displayed with this flag.
(See g++/7470 on how this was used to find bugs.)
</p><p>
Perhaps there are other C++ ABI checkers. If so, please notify
us. We'd like to know about them!
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.testing.multi"></a>Multiple ABI Testing</h4></div></div></div><p>
A "C" application, dynamically linked to two shared libraries, liba,
libb. The dependent library liba is C++ shared library compiled with
gcc-3.3.x, and uses io, exceptions, locale, etc. The dependent library
libb is a C++ shared library compiled with gcc-3.4.x, and also uses io,
exceptions, locale, etc.
</p><p> As above, libone is constructed as follows: </p><pre class="programlisting">
%$bld/H-x86-gcc-3.4.0/bin/g++ -fPIC -DPIC -c a.cc
%$bld/H-x86-gcc-3.4.0/bin/g++ -shared -Wl,-soname -Wl,libone.so.1 -Wl,-O1 -Wl,-z,defs a.o -o libone.so.1.0.0
%ln -s libone.so.1.0.0 libone.so
%$bld/H-x86-gcc-3.4.0/bin/g++ -c a.cc
%ar cru libone.a a.o
</pre><p> And, libtwo is constructed as follows: </p><pre class="programlisting">
%$bld/H-x86-gcc-3.3.3/bin/g++ -fPIC -DPIC -c b.cc
%$bld/H-x86-gcc-3.3.3/bin/g++ -shared -Wl,-soname -Wl,libtwo.so.1 -Wl,-O1 -Wl,-z,defs b.o -o libtwo.so.1.0.0
%ln -s libtwo.so.1.0.0 libtwo.so
%$bld/H-x86-gcc-3.3.3/bin/g++ -c b.cc
%ar cru libtwo.a b.o
</pre><p> ...with the resulting libraries looking like </p><pre class="screen">
<code class="computeroutput">
%ldd libone.so.1.0.0
libstdc++.so.6 =&gt; /usr/lib/libstdc++.so.6 (0x40016000)
libm.so.6 =&gt; /lib/tls/libm.so.6 (0x400fa000)
libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x4011c000)
libc.so.6 =&gt; /lib/tls/libc.so.6 (0x40125000)
/lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
%ldd libtwo.so.1.0.0
libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x40027000)
libm.so.6 =&gt; /lib/tls/libm.so.6 (0x400e1000)
libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40103000)
libc.so.6 =&gt; /lib/tls/libc.so.6 (0x4010c000)
/lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
</code>
</pre><p>
Then, the "C" compiler is used to compile a source file that uses
functions from each library.
</p><pre class="programlisting">
gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.6
</pre><p>
Which gives the expected:
</p><pre class="screen">
<code class="computeroutput">
%ldd a.out
libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x00764000)
libstdc++.so.6 =&gt; /usr/lib/libstdc++.so.6 (0x40015000)
libc.so.6 =&gt; /lib/tls/libc.so.6 (0x0036d000)
libm.so.6 =&gt; /lib/tls/libm.so.6 (0x004a8000)
libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x400e5000)
/lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
</code>
</pre><p>
This resulting binary, when executed, will be able to safely use
code from both liba, and the dependent libstdc++.so.6, and libb,
with the dependent libstdc++.so.5.
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.issues"></a>Outstanding Issues</h3></div></div></div><p>
Some features in the C++ language make versioning especially
difficult. In particular, compiler generated constructs such as
implicit instantiations for templates, typeinfo information, and
virtual tables all may cause ABI leakage across shared library
boundaries. Because of this, mixing C++ ABI's is not recommended at
this time.
</p><p>
For more background on this issue, see these bugzilla entries:
</p><p>
<a class="ulink" href="http://gcc.gnu.org/PR24660" target="_top">24660: versioning weak symbols in libstdc++</a>
</p><p>
<a class="ulink" href="http://gcc.gnu.org/PR19664" target="_top">19664: libstdc++ headers should have pop/push of the visibility around the declarations</a>
</p></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="abi.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id510592"></a><p><span class="title"><i>
ABIcheck, a vague idea of checking ABI compatibility
</i>. </span><span class="biblioid">
<a class="ulink" href="http://abicheck.sourceforge.net/" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id510609"></a><p><span class="title"><i>
C++ ABI Reference
</i>. </span><span class="biblioid">
<a class="ulink" href="http://www.codesourcery.com/cxx-abi" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id510627"></a><p><span class="title"><i>
Intel® Compilers for Linux* -Compatibility with the GNU Compilers
</i>. </span><span class="biblioid">
<a class="ulink" href="http://developer.intel.com/software/products/compilers/techtopics/LinuxCompilersCompatibility.htm" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id510644"></a><p><span class="title"><i>
Intel® Compilers for Linux* -Compatibility with the GNU Compilers
</i>. </span><span class="biblioid">
<a class="ulink" href="http://developer.intel.com/software/products/compilers/techtopics/LinuxCompilersCompatibility.htm" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id510662"></a><p><span class="title"><i>
Sun Solaris 2.9 : Linker and Libraries Guide (document 816-1386)
</i>. </span><span class="biblioid">
<a class="ulink" href="http://docs.sun.com/?p=/doc/816-1386&amp;a=load" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id510679"></a><p><span class="title"><i>
Sun Solaris 2.9 : C++ Migration Guide (document 816-2459)
</i>. </span><span class="biblioid">
<a class="ulink" href="http://docs.sun.com/db/prod/solaris.9" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id510696"></a><p><span class="title"><i>
ELF Symbol Versioning
</i>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="biblioid">
<a class="ulink" href="http://people.redhat.com/drepper/symbol-versioning" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id510725"></a><p><span class="title"><i>
C++ ABI for the ARM Architecture
</i>. </span><span class="biblioid">
<a class="ulink" href="http://www.arm.com/miscPDFs/8033.pdf" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id510742"></a><p><span class="title"><i>
Dynamic Shared Objects: Survey and Issues
</i>. </span><span class="subtitle">
ISO C++ J16/06-0046
. </span><span class="author"><span class="firstname">Benjamin</span> <span class="surname">Kosnik</span>. </span><span class="biblioid">
<a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1976.html" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id499374"></a><p><span class="title"><i>
Versioning With Namespaces
</i>. </span><span class="subtitle">
ISO C++ J16/06-0083
. </span><span class="author"><span class="firstname">Benjamin</span> <span class="surname">Kosnik</span>. </span><span class="biblioid">
<a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2013.html" target="_top">
</a>
. </span></p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="internals.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_porting.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Porting to New Hardware or Operating Systems </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> API Evolution and Deprecation History</td></tr></table></div></body></html>

3
libstdc++-v3/doc/html/manual/algorithms.html Normal file
View File

@ -0,0 +1,3 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part IX. Algorithms</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; , &#10; algorithm&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="bk01pt08ch19s02.html" title="One Past the End" /><link rel="next" href="bk01pt09pr02.html" title="" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part IX. Algorithms</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt08ch19s02.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt09pr02.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.algorithms"></a>Part IX. Algorithms</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="bk01pt09pr02.html"></a></span></dt><dt><span class="chapter"><a href="bk01pt09ch20.html">20. Mutating</a></span></dt><dd><dl><dt><span class="sect1"><a href="bk01pt09ch20.html#algorithms.mutating.swap"><code class="function">swap</code></a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt09ch20.html#algorithms.swap.specializations">Specializations</a></span></dt></dl></dd></dl></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt08ch19s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt09pr02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">One Past the End </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>

151
libstdc++-v3/doc/html/manual/api.html Normal file
View File

@ -0,0 +1,151 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>API Evolution and Deprecation History</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="ISO C++, api, evolution, deprecation, history" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_porting.html" title="Appendix B. Porting and Maintenance" /><link rel="prev" href="abi.html" title="ABI Policy and Guidelines" /><link rel="next" href="backwards.html" title="Backwards Compatibility" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">API Evolution and Deprecation History</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="abi.html">Prev</a> </td><th width="60%" align="center">Appendix B. Porting and Maintenance</th><td width="20%" align="right"> <a accesskey="n" href="backwards.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="appendix.porting.api"></a>API Evolution and Deprecation History</h2></div></div></div><p>
A list of user-visible changes, in cronological order
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_300"></a><code class="constant">3.0</code></h3></div></div></div><p>
Extensions moved to <code class="filename">include/ext</code>.
</p><p>
Include files from the SGI/HP sources that pre-date the ISO standard
are added. These files are placed into
the <code class="filename">include/backward</code> directory and a deprecated warning
is added that notifies on inclusion (<code class="literal">-Wno-deprecated</code>
deactivates the warning.)
</p><p>Deprecated include <code class="filename">backward/strstream</code> added.</p><p>Removal of include <code class="filename">builtinbuf.h</code>, <code class="filename">indstream.h</code>, <code class="filename">parsestream.h</code>, <code class="filename">PlotFile.h</code>, <code class="filename">SFile.h</code>, <code class="filename">stdiostream.h</code>, and <code class="filename">stream.h</code>.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_310"></a><code class="constant">3.1</code></h3></div></div></div><p>
</p><p>
Extensions from SGI/HP moved from <code class="code">namespace std</code>
to <code class="code">namespace __gnu_cxx</code>. As part of this, the following
new includes are
added: <code class="filename">ext/algorithm</code>, <code class="filename">ext/functional</code>, <code class="filename">ext/iterator</code>, <code class="filename">ext/memory</code>, and <code class="filename">ext/numeric</code>.
</p><p>
Extensions to <code class="code">basic_filebuf</code> introduced: <code class="code">__gnu_cxx::enc_filebuf</code>, and <code class="code">__gnu_cxx::stdio_filebuf</code>.
</p><p>
Extensions to tree data structures added in <code class="filename">ext/rb_tree</code>.
</p><p>
Removal of <code class="filename">ext/tree</code>, moved to <code class="filename">backward/tree.h</code>.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_320"></a><code class="constant">3.2</code></h3></div></div></div><p>
</p><p>Symbol versioning introduced for shared library.</p><p>Removal of include <code class="filename">backward/strstream.h</code>.</p><p>Allocator changes. Change <code class="code">__malloc_alloc</code> to <code class="code">malloc_allocator</code> and <code class="code">__new_alloc</code> to <code class="code">new_allocator</code>. </p><p> For GCC releases from 2.95 through the 3.1 series, defining
<code class="literal">__USE_MALLOC</code> on the gcc command line would change the
default allocation strategy to instead use <code class="code"> malloc</code> and
<code class="function">free</code>. See
<a class="ulink" href="../23_containers/howto.html#3" target="_top">this note</a>
for details as to why this was something needing improvement.
</p><p>Error handling in iostreams cleaned up, made consistent. </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_330"></a><code class="constant">3.3</code></h3></div></div></div><p>
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_340"></a><code class="constant">3.4</code></h3></div></div></div><p>
</p><p>
Large file support.
</p><p> Extensions for generic characters and <code class="code">char_traits</code> added in <code class="filename">ext/pod_char_traits.h</code>.
</p><p>
Support for <code class="code">wchar_t</code> specializations of <code class="code">basic_filebuf</code> enhanced to support <code class="code">UTF-8</code> and <code class="code">Unicode</code>, depending on host. More hosts support basic <code class="code">wchar_t</code> functionality.
</p><p>
Support for <code class="code">char_traits</code> beyond builtin types.
</p><p>
Conformant <code class="code">allocator</code> class and usage in containers. As
part of this, the following extensions are
added: <code class="filename">ext/bitmap_allocator.h</code>, <code class="filename">ext/debug_allocator.h</code>, <code class="filename">ext/mt_allocator.h</code>, <code class="filename">ext/malloc_allocator.h</code>,<code class="filename">ext/new_allocator.h</code>, <code class="filename">ext/pool_allocator.h</code>.
</p><p>
This is a change from all previous versions, and may require
source-level changes due to allocator-related changes to structures
names and template parameters, filenames, and file locations. Some,
like <code class="code">__simple_alloc, __allocator, __alloc, </code> and <code class="code">
_Alloc_traits</code> have been removed.
</p><p>Default behavior of <code class="code">std::allocator</code> has changed.</p><p>
Previous versions prior to 3.4 cache allocations in a memory
pool, instead of passing through to call the global allocation
operators (ie, <code class="classname">__gnu_cxx::pool_allocator</code>). More
recent versions default to the
simpler <code class="classname">__gnu_cxx::new_allocator</code>.
</p><p> Previously, all allocators were written to the SGI
style, and all STL containers expected this interface. This
interface had a traits class called <code class="code">_Alloc_traits</code> that
attempted to provide more information for compile-time allocation
selection and optimization. This traits class had another allocator
wrapper, <code class="code">__simple_alloc&lt;T,A&gt;</code>, which was a
wrapper around another allocator, A, which itself is an allocator
for instances of T. But wait, there's more:
<code class="code">__allocator&lt;T,A&gt;</code> is another adapter. Many of
the provided allocator classes were SGI style: such classes can be
changed to a conforming interface with this wrapper:
<code class="code">__allocator&lt;T, __alloc&gt;</code> is thus the same as
<code class="code">allocator&lt;T&gt;</code>.
</p><p> The class <code class="classname">allocator</code> used the typedef
<span class="type">__alloc</span> to select an underlying allocator that
satisfied memory allocation requests. The selection of this
underlying allocator was not user-configurable.
</p><div class="table"><a id="id456920"></a><p class="title"><b>Table B.1. Extension Allocators</b></p><div class="table-contents"><table summary="Extension Allocators" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><thead><tr><th align="left">Allocator (3.4)</th><th align="left">Header (3.4)</th><th align="left">Allocator (3.[0-3])</th><th align="left">Header (3.[0-3])</th></tr></thead><tbody><tr><td align="left"><code class="classname">__gnu_cxx::new_allocator&lt;T&gt;</code></td><td align="left"><code class="filename">ext/new_allocator.h</code></td><td align="left"><code class="classname">std::__new_alloc</code></td><td align="left"><code class="filename">memory</code></td></tr><tr><td align="left"><code class="classname">__gnu_cxx::malloc_allocator&lt;T&gt;</code></td><td align="left"><code class="filename">ext/malloc_allocator.h</code></td><td align="left"><code class="classname">std::__malloc_alloc_template&lt;int&gt;</code></td><td align="left"><code class="filename">memory</code></td></tr><tr><td align="left"><code class="classname">__gnu_cxx::debug_allocator&lt;T&gt;</code></td><td align="left"><code class="filename">ext/debug_allocator.h</code></td><td align="left"><code class="classname">std::debug_alloc&lt;T&gt;</code></td><td align="left"><code class="filename">memory</code></td></tr><tr><td align="left"><code class="classname">__gnu_cxx::__pool_alloc&lt;T&gt;</code></td><td align="left"><code class="filename">ext/pool_allocator.h</code></td><td align="left"><code class="classname">std::__default_alloc_template&lt;bool,int&gt;</code></td><td align="left"><code class="filename">memory</code></td></tr><tr><td align="left"><code class="classname">__gnu_cxx::__mt_alloc&lt;T&gt;</code></td><td align="left"><code class="filename">ext/mt_allocator.h</code></td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left"><code class="classname">__gnu_cxx::bitmap_allocator&lt;T&gt;</code></td><td align="left"><code class="filename">ext/bitmap_allocator.h</code></td><td align="left"> </td><td align="left"> </td></tr></tbody></table></div></div><br class="table-break" /><p> Releases after gcc-3.4 have continued to add to the collection
of available allocators. All of these new allocators are
standard-style. The following table includes details, along with
the first released version of GCC that included the extension allocator.
</p><div class="table"><a id="id408028"></a><p class="title"><b>Table B.2. Extension Allocators Continued</b></p><div class="table-contents"><table summary="Extension Allocators Continued" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /></colgroup><thead><tr><th align="left">Allocator</th><th align="left">Include</th><th align="left">Version</th></tr></thead><tbody><tr><td align="left"><code class="classname">__gnu_cxx::array_allocator&lt;T&gt;</code></td><td align="left"><code class="filename">ext/array_allocator.h</code></td><td align="left">4.0.0</td></tr><tr><td align="left"><code class="classname">__gnu_cxx::throw_allocator&lt;T&gt;</code></td><td align="left"><code class="filename">ext/throw_allocator.h</code></td><td align="left">4.2.0</td></tr></tbody></table></div></div><br class="table-break" /><p>
Debug mode first appears.
</p><p>
Precompiled header support <acronym class="acronym">PCH</acronym> support.
</p><p>
Macro guard for changed, from <code class="literal">_GLIBCPP_</code> to <code class="literal">_GLIBCXX_</code>.
</p><p>
Extension <code class="filename">ext/stdio_sync_filebuf.h</code> added.
</p><p>
Extension <code class="filename">ext/demangle.h</code> added.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_400"></a><code class="constant">4.0</code></h3></div></div></div><p>
</p><p>
TR1 features first appear.
</p><p>
Extension allocator <code class="filename">ext/array_allocator.h</code> added.
</p><p>
Extension <code class="code">codecvt</code> specializations moved to <code class="filename">ext/codecvt_specializations.h</code>.
</p><p>
Removal of <code class="filename">ext/demangle.h</code>.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_410"></a><code class="constant">4.1</code></h3></div></div></div><p>
</p><p>
Removal of <code class="filename">cassert</code> from all standard headers: now has to be explicitly included for <code class="code">std::assert</code> calls.
</p><p> Extensions for policy-based data structures first added. New includes,
types, namespace <code class="code">pb_assoc</code>.
</p><p> Extensions for typelists added in <code class="filename">ext/typelist.h</code>.
</p><p> Extension for policy-based <code class="code">basic_string</code> first added: <code class="code">__gnu_cxx::__versa_string</code> in <code class="filename">ext/vstring.h</code>.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_420"></a><code class="constant">4.2</code></h3></div></div></div><p>
</p><p> Default visibility attributes applied to <code class="code">namespace std</code>. Support for <code class="code">-fvisibility</code>.
</p><p>TR1 <code class="filename">random</code>, <code class="filename">complex</code>, and C compatibility headers added.</p><p> Extensions for concurrent programming consolidated
into <code class="filename">ext/concurrence.h</code> and <code class="filename">ext/atomicity.h</code>,
including change of namespace to <code class="code">__gnu_cxx</code> in some
cases. Added types
include <code class="code">_Lock_policy</code>, <code class="code">__concurrence_lock_error</code>, <code class="code">__concurrence_unlock_error</code>, <code class="code">__mutex</code>, <code class="code">__scoped_lock</code>.</p><p> Extensions for type traits consolidated
into <code class="filename">ext/type_traits.h</code>. Additional traits are added
(<code class="code">__conditional_type</code>, <code class="code">__enable_if</code>, others.)
</p><p> Extensions for policy-based data structures revised. New includes,
types, namespace moved to <code class="code">__pb_ds</code>.
</p><p> Extensions for debug mode modified: now nested in <code class="code">namespace
std::__debug</code> and extensions in <code class="code">namespace
__gnu_cxx::__debug</code>.</p><p> Extensions added: <code class="filename">ext/typelist.h</code>
and <code class="filename">ext/throw_allocator.h</code>.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_430"></a><code class="constant">4.3</code></h3></div></div></div><p>
</p><p>
C++0X features first appear.
</p><p>TR1 <code class="filename">regex</code> and <code class="filename">cmath</code>'s mathematical special function added.</p><p>
Backward include edit.
</p><div class="itemizedlist"><ul type="disc"><li><p>Removed</p><p>
<code class="filename">algobase.h</code> <code class="filename">algo.h</code> <code class="filename">alloc.h</code> <code class="filename">bvector.h</code> <code class="filename">complex.h</code>
<code class="filename">defalloc.h</code> <code class="filename">deque.h</code> <code class="filename">fstream.h</code> <code class="filename">function.h</code> <code class="filename">hash_map.h</code> <code class="filename">hash_set.h</code>
<code class="filename">hashtable.h</code> <code class="filename">heap.h</code> <code class="filename">iomanip.h</code> <code class="filename">iostream.h</code> <code class="filename">istream.h</code> <code class="filename">iterator.h</code>
<code class="filename">list.h</code> <code class="filename">map.h</code> <code class="filename">multimap.h</code> <code class="filename">multiset.h</code> <code class="filename">new.h</code> <code class="filename">ostream.h</code> <code class="filename">pair.h</code> <code class="filename">queue.h</code> <code class="filename">rope.h</code> <code class="filename">set.h</code> <code class="filename">slist.h</code> <code class="filename">stack.h</code> <code class="filename">streambuf.h</code> <code class="filename">stream.h</code> <code class="filename">tempbuf.h</code>
<code class="filename">tree.h</code> <code class="filename">vector.h</code>
</p></li><li><p>Added</p><p>
<code class="filename">hash_map</code> and <code class="filename">hash_set</code>
</p></li><li><p>Added in C++0x</p><p>
<code class="filename">auto_ptr.h</code> and <code class="filename">binders.h</code>
</p></li></ul></div><p>
Header dependency streamlining.
</p><div class="itemizedlist"><ul type="disc"><li><p><code class="filename">algorithm</code> no longer includes <code class="filename">climits</code>, <code class="filename">cstring</code>, or <code class="filename">iosfwd</code> </p></li><li><p><code class="filename">bitset</code> no longer includes <code class="filename">istream</code> or <code class="filename">ostream</code>, adds <code class="filename">iosfwd</code> </p></li><li><p><code class="filename">functional</code> no longer includes <code class="filename">cstddef</code></p></li><li><p><code class="filename">iomanip</code> no longer includes <code class="filename">istream</code>, <code class="filename">istream</code>, or <code class="filename">functional</code>, adds <code class="filename">ioswd</code> </p></li><li><p><code class="filename">numeric</code> no longer includes <code class="filename">iterator</code></p></li><li><p><code class="filename">string</code> no longer includes <code class="filename">algorithm</code> or <code class="filename">memory</code></p></li><li><p><code class="filename">valarray</code> no longer includes <code class="filename">numeric</code> or <code class="filename">cstdlib</code></p></li><li><p><code class="filename">tr1/hashtable</code> no longer includes <code class="filename">memory</code> or <code class="filename">functional</code></p></li><li><p><code class="filename">tr1/memory</code> no longer includes <code class="filename">algorithm</code></p></li><li><p><code class="filename">tr1/random</code> no longer includes <code class="filename">algorithm</code> or <code class="filename">fstream</code></p></li></ul></div><p>
Debug mode for <code class="filename">unordered_map</code> and <code class="filename">unordered_set</code>.
</p><p>
Parallel mode first appears.
</p><p>Variadic template implementations of items in <code class="filename">tuple</code> and
<code class="filename">functional</code>.
</p><p>Default <code class="code">what</code> implementations give more elaborate
exception strings for <code class="code">bad_cast</code>,
<code class="code">bad_typeid</code>, <code class="code">bad_exception</code>, and
<code class="code">bad_alloc</code>.
</p><p>
PCH binary files no longer installed. Instead, the source files are installed.
</p><p>
Namespace pb_ds moved to __gnu_pb_ds.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="abi.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_porting.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="backwards.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">ABI Policy and Guidelines </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Backwards Compatibility</td></tr></table></div></body></html>

107
libstdc++-v3/doc/html/manual/appendix_contributing.html Normal file
View File

@ -0,0 +1,107 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Appendix A. Contributing</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="bk01pt12ch40s03.html" title="Use" /><link rel="next" href="bk01apas02.html" title="Directory Layout and Source Conventions" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix A. Contributing</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch40s03.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="bk01apas02.html">Next</a></td></tr></table><hr /></div><div class="appendix" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="appendix.contrib"></a>Appendix A. Contributing</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="appendix_contributing.html#contrib.list">Contributor Checklist</a></span></dt><dd><dl><dt><span class="sect2"><a href="appendix_contributing.html#list.reading">Reading</a></span></dt><dt><span class="sect2"><a href="appendix_contributing.html#list.copyright">Assignment</a></span></dt><dt><span class="sect2"><a href="appendix_contributing.html#list.getting">Getting Sources</a></span></dt><dt><span class="sect2"><a href="appendix_contributing.html#list.patches">Submitting Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01apas02.html">Directory Layout and Source Conventions</a></span></dt><dt><span class="sect1"><a href="bk01apas03.html">Coding Style</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01apas03.html#coding_style.bad_identifiers">Bad Itentifiers</a></span></dt><dt><span class="sect2"><a href="bk01apas03.html#coding_style.example">By Example</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01apas04.html">Documentation Style</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01apas04.html#doc_style.doxygen">Doxygen</a></span></dt><dt><span class="sect2"><a href="bk01apas04.html#doc_style.docbook">Docbook</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01apas05.html">Design Notes</a></span></dt></dl></div><p>
The GNU C++ Library follows an open development model. Active
contributors are assigned maintainer-ship responsibility, and given
write access to the source repository. First time contributors
should follow this procedure:
</p><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contrib.list"></a>Contributor Checklist</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="list.reading"></a>Reading</h3></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Get and read the relevant sections of the C++ language
specification. Copies of the full ISO 14882 standard are
available on line via the ISO mirror site for committee
members. Non-members, or those who have not paid for the
privilege of sitting on the committee and sustained 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 web-site is right
<a class="ulink" href="http://www.ansi.org" target="_top">here.</a>
(And if you've already registered with them, clicking this link will take you to directly to the place where you can
<a class="ulink" href="http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%3A2003" target="_top">buy the standard on-line.)</a>
</p></li><li><p>
The library working group bugs, and known defects, can
be obtained here:
<a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/" target="_top">http://www.open-std.org/jtc1/sc22/wg21 </a>
</p></li><li><p>
The newsgroup dedicated to standardization issues is
comp.std.c++: this FAQ for this group is quite useful and
can be
found <a class="ulink" href="http://www.jamesd.demon.co.uk/csc/faq.html" target="_top">
here </a>.
</p></li><li><p>
Peruse
the <a class="ulink" href="http://www.gnu.org/prep/standards_toc.html" target="_top">GNU
Coding Standards</a>, and chuckle when you hit the part
about “<span class="quote">Using Languages Other Than C</span>”.
</p></li><li><p>
Be familiar with the extensions that preceded these
general GNU rules. These style issues for libstdc++ can be
found <a class="link" href="bk01apas03.html" title="Coding Style">here</a>.
</p></li><li><p>
And last but certainly not least, read the
library-specific information
found <a class="link" href="appendix_porting.html" title="Appendix B. Porting and Maintenance"> here</a>.
</p></li></ul></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="list.copyright"></a>Assignment</h3></div></div></div><p>
Small changes can be accepted without a copyright assignment form on
file. New code and additions to the library need completed copyright
assignment form on file at the FSF. Note: your employer may be required
to fill out appropriate disclaimer forms as well.
</p><p>
Historically, the libstdc++ assignment form added the following
question:
</p><p>
“<span class="quote">
Which Belgian comic book character is better, Tintin or Asterix, and
why?
</span>”
</p><p>
While not strictly necessary, humoring the maintainers and answering
this question would be appreciated.
</p><p>
For more information about getting a copyright assignment, please see
<a class="ulink" href="http://www.gnu.org/prep/maintain/html_node/Legal-Matters.html" target="_top">Legal
Matters</a>.
</p><p>
Please contact Benjamin Kosnik at
<code class="email">&lt;<a class="email" href="mailto:bkoz+assign@redhat.com">bkoz+assign@redhat.com</a>&gt;</code> if you are confused
about the assignment or have general licensing questions. When
requesting an assignment form from
<code class="email">&lt;<a class="email" href="mailto:mailto:assign@gnu.org">mailto:assign@gnu.org</a>&gt;</code>, please cc the libstdc++
maintainer above so that progress can be monitored.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="list.getting"></a>Getting Sources</h3></div></div></div><p>
<a class="ulink" href="http://gcc.gnu.org/svnwrite.html" target="_top">Getting write access
(look for "Write after approval")</a>
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="list.patches"></a>Submitting Patches</h3></div></div></div><p>
Every patch must have several pieces of information before it can be
properly evaluated. Ideally (and to ensure the fastest possible
response from the maintainers) it would have all of these pieces:
</p><div class="itemizedlist"><ul type="disc"><li><p>
A description of the bug and how your patch fixes this
bug. For new features a description of the feature and your
implementation.
</p></li><li><p>
A ChangeLog entry as plain text; see the various
ChangeLog files for format and content. If using you are
using emacs as your editor, simply position the insertion
point at the beginning of your change and hit CX-4a to bring
up the appropriate ChangeLog entry. See--magic! Similar
functionality also exists for vi.
</p></li><li><p>
A testsuite submission or sample program that will
easily and simply show the existing error or test new
functionality.
</p></li><li><p>
The patch itself. If you are accessing the SVN
repository use <span class="command"><strong>svn update; svn diff NEW</strong></span>;
else, use <span class="command"><strong>diff -cp OLD NEW</strong></span> ... If your
version of diff does not support these options, then get the
latest version of GNU
diff. The <a class="ulink" href="http://gcc.gnu.org/wiki/SvnTricks" target="_top">SVN
Tricks</a> wiki page has information on customising the
output of <code class="code">svn diff</code>.
</p></li><li><p>
When you have all these pieces, bundle them up in a
mail message and send it to libstdc++@gcc.gnu.org. All
patches and related discussion should be sent to the
libstdc++ mailing list.
</p></li></ul></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch40s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01apas02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Use </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Directory Layout and Source Conventions</td></tr></table></div></body></html>

116
libstdc++-v3/doc/html/manual/appendix_free.html Normal file
View File

@ -0,0 +1,116 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Appendix C. Free Software Needs Free Documentation</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="backwards.html" title="Backwards Compatibility" /><link rel="next" href="bk01apd.html" title="Appendix D. GNU General Public License" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix C. Free Software Needs Free Documentation</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="backwards.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="bk01apd.html">Next</a></td></tr></table><hr /></div><div class="appendix" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="appendix.free"></a>Appendix C. Free Software Needs Free Documentation</h2></div></div></div><p>
The biggest deficiency in free operating systems is not in the
software--it is the lack of good free manuals that we can include in
these systems. Many of our most important programs do not come with
full manuals. Documentation is an essential part of any software
package; when an important free software package does not come with a
free manual, that is a major gap. We have many such gaps today.
</p><p>
Once upon a time, many years ago, I thought I would learn Perl. I got
a copy of a free manual, but I found it hard to read. When I asked
Perl users about alternatives, they told me that there were better
introductory manuals--but those were not free.
</p><p>
Why was this? The authors of the good manuals had written them for
O'Reilly Associates, which published them with restrictive terms--no
copying, no modification, source files not available--which exclude
them from the free software community.
</p><p>
That wasn't the first time this sort of thing has happened, and (to
our community's great loss) it was far from the last. Proprietary
manual publishers have enticed a great many authors to restrict their
manuals since then. Many times I have heard a GNU user eagerly tell
me about a manual that he is writing, with which he expects to help
the GNU project--and then had my hopes dashed, as he proceeded to
explain that he had signed a contract with a publisher that would
restrict it so that we cannot use it.
</p><p>
Given that writing good English is a rare skill among programmers, we
can ill afford to lose manuals this way.
</p><p>
Free documentation, like free software, is a matter of freedom,
not price. The problem with these manuals was not that O'Reilly
Associates charged a price for printed copies--that in itself is fine.
(The Free Software Foundation <a class="ulink" href="http://www.gnu.org/doc/doc.html" target="_top">sells printed copies</a> of
free GNU manuals, too.) But GNU manuals are available in source code
form, while these manuals are available only on paper. GNU manuals
come with permission to copy and modify; the Perl manuals do not.
These restrictions are the problems.
</p><p>
The criterion for a free manual is pretty much the same as for free
software: it is a matter of giving all users certain freedoms.
Redistribution (including commercial redistribution) must be
permitted, so that the manual can accompany every copy of the program,
on-line or on paper. Permission for modification is crucial too.
</p><p>
As a general rule, I don't believe that it is essential for people to
have permission to modify all sorts of articles and books. The issues
for writings are not necessarily the same as those for software. For
example, I don't think you or I are obliged to give permission to
modify articles like this one, which describe our actions and our
views.
</p><p>
But there is a particular reason why the freedom to modify is crucial
for documentation for free software. When people exercise their right
to modify the software, and add or change its features, if they are
conscientious they will change the manual too--so they can provide
accurate and usable documentation with the modified program. A manual
which forbids programmers to be conscientious and finish the job, or
more precisely requires them to write a new manual from scratch if
they change the program, does not fill our community's needs.
</p><p>
While a blanket prohibition on modification is unacceptable, some
kinds of limits on the method of modification pose no problem. For
example, requirements to preserve the original author's copyright
notice, the distribution terms, or the list of authors, are ok. It is
also no problem to require modified versions to include notice that
they were modified, even to have entire sections that may not be
deleted or changed, as long as these sections deal with nontechnical
topics. (Some GNU manuals have them.)
</p><p>
These kinds of restrictions are not a problem because, as a practical
matter, they don't stop the conscientious programmer from adapting the
manual to fit the modified program. In other words, they don't block
the free software community from making full use of the manual.
</p><p>
However, it must be possible to modify all the <span class="emphasis"><em>technical</em></span>
content of the manual, and then distribute the result in all the usual
media, through all the usual channels; otherwise, the restrictions do
block the community, the manual is not free, and so we need another
manual.
</p><p>
Unfortunately, it is often hard to find someone to write another
manual when a proprietary manual exists. The obstacle is that many
users think that a proprietary manual is good enough--so they don't
see the need to write a free manual. They do not see that the free
operating system has a gap that needs filling.
</p><p>
Why do users think that proprietary manuals are good enough? Some
have not considered the issue. I hope this article will do something
to change that.
</p><p>
Other users consider proprietary manuals acceptable for the same
reason so many people consider proprietary software acceptable: they
judge in purely practical terms, not using freedom as a criterion.
These people are entitled to their opinions, but since those opinions
spring from values which do not include freedom, they are no guide for
those of us who do value freedom.
</p><p>
Please spread the word about this issue. We continue to lose manuals
to proprietary publishing. If we spread the word that proprietary
manuals are not sufficient, perhaps the next person who wants to help
GNU by writing documentation will realize, before it is too late, that
he must above all make it free.
</p><p>
We can also encourage commercial publishers to sell free, copylefted
manuals instead of proprietary ones. One way you can help this is to
check the distribution terms of a manual before you buy it, and
prefer copylefted manuals to non-copylefted ones.
</p><p>
[Note: We now maintain a <a class="ulink" href="http://www.fsf.org/licensing/doc/other-free-books.html" target="_top">web page
that lists free books available from other publishers</a>].
</p><p>Copyright © 2004, 2005, 2006, 2007 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA</p><p>Verbatim copying and distribution of this entire article are
permitted worldwide, without royalty, in any medium, provided this
notice is preserved.</p><p>Report any problems or suggestions to <code class="email">&lt;<a class="email" href="mailto:webmaster@fsf.org">webmaster@fsf.org</a>&gt;</code>.</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="backwards.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01apd.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Backwards Compatibility </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix D. GNU General Public License</td></tr></table></div></body></html>

224
libstdc++-v3/doc/html/manual/appendix_porting.html Normal file
View File

File diff suppressed because one or more lines are too long

90
libstdc++-v3/doc/html/manual/auto_ptr.html Normal file
View File

@ -0,0 +1,90 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>auto_ptr</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; auto_ptr&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt04ch11.html" title="Chapter 11. Memory" /><link rel="prev" href="bk01pt04ch11.html" title="Chapter 11. Memory" /><link rel="next" href="shared_ptr.html" title="shared_ptr" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">auto_ptr</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt04ch11.html">Prev</a> </td><th width="60%" align="center">Chapter 11. Memory</th><td width="20%" align="right"> <a accesskey="n" href="shared_ptr.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.util.memory.auto_ptr"></a>auto_ptr</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="auto_ptr.limitations"></a>Limitations</h3></div></div></div><p>Explaining all of the fun and delicious things that can
happen with misuse of the <code class="classname">auto_ptr</code> class
template (called <acronym class="acronym">AP</acronym> here) would take some
time. Suffice it to say that the use of <acronym class="acronym">AP</acronym>
safely in the presence of copying has some subtleties.
</p><p>
The AP class is a really
nifty idea for a smart pointer, but it is one of the dumbest of
all the smart pointers -- and that's fine.
</p><p>
AP is not meant to be a supersmart solution to all resource
leaks everywhere. Neither is it meant to be an effective form
of garbage collection (although it can help, a little bit).
And it can <span class="emphasis"><em>not</em></span>be used for arrays!
</p><p>
<acronym class="acronym">AP</acronym> is meant to prevent nasty leaks in the
presence of exceptions. That's <span class="emphasis"><em>all</em></span>. This
code is AP-friendly:
</p><pre class="programlisting">
// Not a recommend naming scheme, but good for web-based FAQs.
typedef std::auto_ptr&lt;MyClass&gt; APMC;
extern function_taking_MyClass_pointer (MyClass*);
extern some_throwable_function ();
void func (int data)
{
APMC ap (new MyClass(data));
some_throwable_function(); // this will throw an exception
function_taking_MyClass_pointer (ap.get());
}
</pre><p>When an exception gets thrown, the instance of MyClass that's
been created on the heap will be <code class="function">delete</code>'d as the stack is
unwound past <code class="function">func()</code>.
</p><p>Changing that code as follows is not <acronym class="acronym">AP</acronym>-friendly:
</p><pre class="programlisting">
APMC ap (new MyClass[22]);
</pre><p>You will get the same problems as you would without the use
of <acronym class="acronym">AP</acronym>:
</p><pre class="programlisting">
char* array = new char[10]; // array new...
...
delete array; // ...but single-object delete
</pre><p>
AP cannot tell whether the pointer you've passed at creation points
to one or many things. If it points to many things, you are about
to die. AP is trivial to write, however, so you could write your
own <code class="code">auto_array_ptr</code> for that situation (in fact, this has
been done many times; check the mailing lists, Usenet, Boost, etc).
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="auto_ptr.using"></a>Use in Containers</h3></div></div></div><p>
</p><p>All of the <a class="ulink" href="../23_containers/howto.html" target="_top">containers</a>
described in the standard library require their contained types
to have, among other things, a copy constructor like this:
</p><pre class="programlisting">
struct My_Type
{
My_Type (My_Type const&amp;);
};
</pre><p>
Note the const keyword; the object being copied shouldn't change.
The template class <code class="code">auto_ptr</code> (called AP here) does not
meet this requirement. Creating a new AP by copying an existing
one transfers ownership of the pointed-to object, which means that
the AP being copied must change, which in turn means that the
copy ctors of AP do not take const objects.
</p><p>
The resulting rule is simple: <span class="emphasis"><em>Never ever use a
container of auto_ptr objects</em></span>. The standard says that
“<span class="quote">undefined</span>” behavior is the result, but it is
guaranteed to be messy.
</p><p>
To prevent you from doing this to yourself, the
<a class="ulink" href="../19_diagnostics/howto.html#3" target="_top">concept checks</a> built
in to this implementation will issue an error if you try to
compile code like this:
</p><pre class="programlisting">
#include &lt;vector&gt;
#include &lt;memory&gt;
void f()
{
std::vector&lt; std::auto_ptr&lt;int&gt; &gt; vec_ap_int;
}
</pre><p>
Should you try this with the checks enabled, you will see an error.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt04ch11.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt04ch11.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="shared_ptr.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 11. Memory </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> shared_ptr</td></tr></table></div></body></html>

926
libstdc++-v3/doc/html/manual/backwards.html Normal file
View File

@ -0,0 +1,926 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Backwards Compatibility</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; backwards&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_porting.html" title="Appendix B. Porting and Maintenance" /><link rel="prev" href="api.html" title="API Evolution and Deprecation History" /><link rel="next" href="appendix_free.html" title="Appendix C. Free Software Needs Free Documentation" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Backwards Compatibility</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="api.html">Prev</a> </td><th width="60%" align="center">Appendix B. Porting and Maintenance</th><td width="20%" align="right"> <a accesskey="n" href="appendix_free.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.appendix.porting.backwards"></a>Backwards Compatibility</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.first"></a>First</h3></div></div></div><p>The first generation GNU C++ library was called libg++. It was a
separate GNU project, although reliably paired with GCC. Rumors imply
that it had a working relationship with at least two kinds of
dinosaur.
</p><p>Some background: libg++ was designed and created when there was no
ISO standard to provide guidance. Classes like linked lists are now
provided for by <code class="classname">list&lt;T&gt;</code> and do not need to be
created by <code class="function">genclass</code>. (For that matter, templates exist
now and are well-supported, whereas genclass (mostly) predates them.)
</p><p>There are other classes in libg++ that are not specified in the
ISO Standard (e.g., statistical analysis). While there are a lot of
really useful things that are used by a lot of people, the Standards
Committee couldn't include everything, and so a lot of those
“<span class="quote">obvious</span>” classes didn't get included.
</p><p>Known Issues include many of the limitations of its immediate ancestor.</p><p>Portability notes and known implementation limitations are as follows.</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id390292"></a>No <code class="code">ios_base</code></h4></div></div></div><p> At least some older implementations don't have <code class="code">std::ios_base</code>, so you should use <code class="code">std::ios::badbit</code>, <code class="code">std::ios::failbit</code> and <code class="code">std::ios::eofbit</code> and <code class="code">std::ios::goodbit</code>.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id390324"></a>No <code class="code">cout</code> in <code class="code">ostream.h</code>, no <code class="code">cin</code> in <code class="code">istream.h</code></h4></div></div></div><p>
In earlier versions of the standard,
<code class="filename">fstream.h</code>,
<code class="filename">ostream.h</code>
and <code class="filename">istream.h</code>
used to define
<code class="code">cout</code>, <code class="code">cin</code> and so on. ISO C++ specifies that one needs to include
<code class="filename">iostream</code>
explicitly to get the required definitions.
</p><p> Some include adjustment may be required.</p><p>This project is no longer maintained or supported, and the sources
archived. For the desperate,
the <a class="ulink" href="http://gcc.gnu.org/extensions.html" target="_top">GCC extensions
page</a> describes where to find the last libg++ source. The code is
considered replaced and rewritten.
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.second"></a>Second</h3></div></div></div><p>
The second generation GNU C++ library was called libstdc++, or
libstdc++-v2. It spans the time between libg++ and pre-ISO C++
standardization and is usually associated with the following GCC
releases: egcs 1.x, gcc 2.95, and gcc 2.96.
</p><p>
The STL portions of this library are based on SGI/HP STL release 3.11.
</p><p>
This project is no longer maintained or supported, and the sources
archived. The code is considered replaced and rewritten.
</p><p>
Portability notes and known implementation limitations are as follows.
</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id390424"></a>Namespace <code class="code">std::</code> not supported</h4></div></div></div><p>
Some care is required to support C++ compiler and or library
implementation that do not have the standard library in
<code class="code">namespace std</code>.
</p><p>
The following sections list some possible solutions to support compilers
that cannot ignore <code class="code">std::</code>-qualified names.
</p><p>
First, see if the compiler has a flag for this. Namespace
back-portability-issues are generally not a problem for g++
compilers that do not have libstdc++ in <code class="code">std::</code>, as the
compilers use <code class="code">-fno-honor-std</code> (ignore
<code class="code">std::</code>, <code class="code">:: = std::</code>) by default. That is,
the responsibility for enabling or disabling <code class="code">std::</code> is
on the user; the maintainer does not have to care about it. This
probably applies to some other compilers as well.
</p><p>
Second, experiment with a variety of pre-processor tricks.
</p><p>
By defining <code class="code">std</code> as a macro, fully-qualified namespace
calls become global. Volia.
</p><pre class="programlisting">
#ifdef WICKEDLY_OLD_COMPILER
# define std
#endif
</pre><p>
Thanks to Juergen Heinzl who posted this solution on gnu.gcc.help.
</p><p>
Another pre-processor based approach is to define a macro
<code class="code">NAMESPACE_STD</code>, which is defined to either
“<span class="quote"> </span>” or “<span class="quote">std</span>” based on a compile-type
test. On GNU systems, this can be done with autotools by means of
an autoconf test (see below) for <code class="code">HAVE_NAMESPACE_STD</code>,
then using that to set a value for the <code class="code">NAMESPACE_STD</code>
macro. At that point, one is able to use
<code class="code">NAMESPACE_STD::string</code>, which will evaluate to
<code class="code">std::string</code> or <code class="code">::string</code> (ie, in the
global namespace on systems that do not put <code class="code">string</code> in
<code class="code">std::</code>).
</p><pre class="programlisting">
dnl @synopsis AC_CXX_NAMESPACE_STD
dnl
dnl If the compiler supports namespace std, define
dnl HAVE_NAMESPACE_STD.
dnl
dnl @category Cxx
dnl @author Todd Veldhuizen
dnl @author Luc Maisonobe &lt;luc@spaceroots.org&gt;
dnl @version 2004-02-04
dnl @license AllPermissive
AC_DEFUN([AC_CXX_NAMESPACE_STD], [
AC_CACHE_CHECK(if g++ supports namespace std,
ac_cv_cxx_have_std_namespace,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([#include &lt;iostream&gt;
std::istream&amp; is = std::cin;],,
ac_cv_cxx_have_std_namespace=yes, ac_cv_cxx_have_std_namespace=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_have_std_namespace" = yes; then
AC_DEFINE(HAVE_NAMESPACE_STD,,[Define if g++ supports namespace std. ])
fi
])
</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id393816"></a>Illegal iterator usage</h4></div></div></div><p>
The following illustrate implementation-allowed illegal iterator
use, and then correct use.
</p><div class="itemizedlist"><ul type="disc"><li><p>
you cannot do <code class="code">ostream::operator&lt;&lt;(iterator)</code>
to print the address of the iterator =&gt; use
<code class="code">operator&lt;&lt; &amp;*iterator</code> instead
</p></li><li><p>
you cannot clear an iterator's reference (<code class="code">iterator =
0</code>) =&gt; use <code class="code">iterator = iterator_type();</code>
</p></li><li><p>
<code class="code">if (iterator)</code> won't work any more =&gt; use
<code class="code">if (iterator != iterator_type())</code>
</p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id393877"></a><code class="code">isspace</code> from <code class="filename">cctype</code> is a macro
</h4></div></div></div><p>
Glibc 2.0.x and 2.1.x define <code class="filename">ctype.h</code> functionality as macros
(isspace, isalpha etc.).
</p><p>
This implementations of libstdc++, however, keep these functions
as macros, and so it is not back-portable to use fully qualified
names. For example:
</p><pre class="programlisting">
#include &lt;cctype&gt;
int main() { std::isspace('X'); }
</pre><p>
Results in something like this:
</p><pre class="programlisting">
std:: (__ctype_b[(int) ( ( 'X' ) )] &amp; (unsigned short int) _ISspace ) ;
</pre><p>
A solution is to modify a header-file so that the compiler tells
<code class="filename">ctype.h</code> to define functions
instead of macros:
</p><pre class="programlisting">
// This keeps isalnum, et al from being propagated as macros.
#if __linux__
# define __NO_CTYPE 1
#endif
</pre><p>
Then, include <code class="filename">ctype.h</code>
</p><p>
Another problem arises if you put a <code class="code">using namespace
std;</code> declaration at the top, and include <code class="filename">ctype.h</code>. This will result in
ambiguities between the definitions in the global namespace
(<code class="filename">ctype.h</code>) and the
definitions in namespace <code class="code">std::</code>
(<code class="code">&lt;cctype&gt;</code>).
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id450846"></a>No <code class="code">vector::at</code>, <code class="code">deque::at</code>, <code class="code">string::at</code></h4></div></div></div><p>
One solution is to add an autoconf-test for this:
</p><pre class="programlisting">
AC_MSG_CHECKING(for container::at)
AC_TRY_COMPILE(
[
#include &lt;vector&gt;
#include &lt;deque&gt;
#include &lt;string&gt;
using namespace std;
],
[
deque&lt;int&gt; test_deque(3);
test_deque.at(2);
vector&lt;int&gt; test_vector(2);
test_vector.at(1);
string test_string(“<span class="quote">test_string</span>”);
test_string.at(3);
],
[AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_CONTAINER_AT)],
[AC_MSG_RESULT(no)])
</pre><p>
If you are using other (non-GNU) compilers it might be a good idea
to check for <code class="code">string::at</code> separately.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id450884"></a>No <code class="code">std::char_traits&lt;char&gt;::eof</code></h4></div></div></div><p>
Use some kind of autoconf test, plus this:
</p><pre class="programlisting">
#ifdef HAVE_CHAR_TRAITS
#define CPP_EOF std::char_traits&lt;char&gt;::eof()
#else
#define CPP_EOF EOF
#endif
</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id450902"></a>No <code class="code">string::clear</code></h4></div></div></div><p>
There are two functions for deleting the contents of a string:
<code class="code">clear</code> and <code class="code">erase</code> (the latter returns the
string).
</p><pre class="programlisting">
void
clear() { _M_mutate(0, this-&gt;size(), 0); }
</pre><pre class="programlisting">
basic_string&amp;
erase(size_type __pos = 0, size_type __n = npos)
{
return this-&gt;replace(_M_check(__pos), _M_fold(__pos, __n),
_M_data(), _M_data());
}
</pre><p>
Unfortunately, ut <code class="code">clear</code> is not implemented in this
version, so you should use <code class="code">erase</code> (which is probably
faster than <code class="code">operator=(charT*)</code>).
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id450947"></a>
Removal of <code class="code">ostream::form</code> and <code class="code">istream::scan</code>
extensions
</h4></div></div></div><p>
These are no longer supported. Please use stringstreams instead.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id450966"></a>No <code class="code">basic_stringbuf</code>, <code class="code">basic_stringstream</code></h4></div></div></div><p>
Although the ISO standard <code class="code">i/ostringstream</code>-classes are
provided, (<code class="filename">sstream</code>), for
compatibility with older implementations the pre-ISO
<code class="code">i/ostrstream</code> (<code class="filename">strstream</code>) interface is also provided,
with these caveats:
</p><div class="itemizedlist"><ul type="disc"><li><p>
<code class="code">strstream</code> is considered to be deprecated
</p></li><li><p>
<code class="code">strstream</code> is limited to <code class="code">char</code>
</p></li><li><p>
with <code class="code">ostringstream</code> you don't have to take care of
terminating the string or freeing its memory
</p></li><li><p>
<code class="code">istringstream</code> can be re-filled (clear();
str(input);)
</p></li></ul></div><p>
You can then use output-stringstreams like this:
</p><pre class="programlisting">
#ifdef HAVE_SSTREAM
# include &lt;sstream&gt;
#else
# include &lt;strstream&gt;
#endif
#ifdef HAVE_SSTREAM
std::ostringstream oss;
#else
std::ostrstream oss;
#endif
oss &lt;&lt; “<span class="quote">Name=</span>” &lt;&lt; m_name &lt;&lt; “<span class="quote">, number=</span>” &lt;&lt; m_number &lt;&lt; std::endl;
...
#ifndef HAVE_SSTREAM
oss &lt;&lt; std::ends; // terminate the char*-string
#endif
// str() returns char* for ostrstream and a string for ostringstream
// this also causes ostrstream to think that the buffer's memory
// is yours
m_label.set_text(oss.str());
#ifndef HAVE_SSTREAM
// let the ostrstream take care of freeing the memory
oss.freeze(false);
#endif
</pre><p>
Input-stringstreams can be used similarly:
</p><pre class="programlisting">
std::string input;
...
#ifdef HAVE_SSTREAM
std::istringstream iss(input);
#else
std::istrstream iss(input.c_str());
#endif
int i;
iss &gt;&gt; i;
</pre><p> One (the only?) restriction is that an istrstream cannot be re-filled:
</p><pre class="programlisting">
std::istringstream iss(numerator);
iss &gt;&gt; m_num;
// this is not possible with istrstream
iss.clear();
iss.str(denominator);
iss &gt;&gt; m_den;
</pre><p>
If you don't care about speed, you can put these conversions in
a template-function:
</p><pre class="programlisting">
template &lt;class X&gt;
void fromString(const string&amp; input, X&amp; any)
{
#ifdef HAVE_SSTREAM
std::istringstream iss(input);
#else
std::istrstream iss(input.c_str());
#endif
X temp;
iss &gt;&gt; temp;
if (iss.fail())
throw runtime_error(..)
any = temp;
}
</pre><p>
Another example of using stringstreams is in <a class="link" href="bk01pt05ch13s05.html" title="Shrink to Fit">this howto</a>.
</p><p> There is additional information in the libstdc++-v2 info files, in
particular “<span class="quote">info iostream</span>”.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id451118"></a>Little or no wide character support</h4></div></div></div><p>
Classes <code class="classname">wstring</code> and
<code class="classname">char_traits&lt;wchar_t&gt;</code> are
not supported.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id451137"></a>No templatized iostreams</h4></div></div></div><p>
Classes <code class="classname">wfilebuf</code> and
<code class="classname">wstringstream</code> are not supported.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id451156"></a>Thread safety issues</h4></div></div></div><p>
Earlier GCC releases had a somewhat different approach to
threading configuration and proper compilation. Before GCC 3.0,
configuration of the threading model was dictated by compiler
command-line options and macros (both of which were somewhat
thread-implementation and port-specific). There were no
guarantees related to being able to link code compiled with one
set of options and macro setting with another set.
</p><p>
For GCC 3.0, configuration of the threading model used with
libraries and user-code is performed when GCC is configured and
built using the --enable-threads and --disable-threads options.
The ABI is stable for symbol name-mangling and limited functional
compatibility exists between code compiled under different
threading models.
</p><p>
The libstdc++ library has been designed so that it can be used in
multithreaded applications (with libstdc++-v2 this was only true
of the STL parts.) The first problem is finding a
<span class="emphasis"><em>fast</em></span> method of implementation portable to
all platforms. Due to historical reasons, some of the library is
written against per-CPU-architecture spinlocks and other parts
against the gthr.h abstraction layer which is provided by gcc. A
minor problem that pops up every so often is different
interpretations of what "thread-safe" means for a
library (not a general program). We currently use the <a class="ulink" href="http://www.sgi.com/tech/stl/thread_safety.html" target="_top">same
definition that SGI</a> uses for their STL subset. However,
the exception for read-only containers only applies to the STL
components. This definition is widely-used and something similar
will be used in the next version of the C++ standard library.
</p><p>
Here is a small link farm to threads (no pun) in the mail
archives that discuss the threading problem. Each link is to the
first relevant message in the thread; from there you can use
"Thread Next" to move down the thread. This farm is in
latest-to-oldest order.
</p><div class="itemizedlist"><ul type="disc"><li><p>
Our threading expert Loren gives a breakdown of <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2001-10/msg00024.html" target="_top">the
six situations involving threads</a> for the 3.0
release series.
</p></li><li><p>
<a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html" target="_top">
This message</a> inspired a recent updating of issues with
threading and the SGI STL library. It also contains some
example POSIX-multithreaded STL code.
</p></li></ul></div><p>
(A large selection of links to older messages has been removed;
many of the messages from 1999 were lost in a disk crash, and the
few people with access to the backup tapes have been too swamped
with work to restore them. Many of the points have been
superseded anyhow.)
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.third"></a>Third</h3></div></div></div><p> The third generation GNU C++ library is called libstdc++, or
libstdc++-v3.
</p><p>The subset commonly known as the Standard Template Library
(chapters 23 through 25, mostly) is adapted from the final release
of the SGI STL (version 3.3), with extensive changes.
</p><p>A more formal description of the V3 goals can be found in the
official <a class="ulink" href="../17_intro/DESIGN" target="_top">design document</a>.
</p><p>Portability notes and known implementation limitations are as follows.</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id516132"></a>Pre-ISO headers moved to backwards or removed</h4></div></div></div><p> The pre-ISO C++ headers
(<code class="code">iostream.h</code>, <code class="code">defalloc.h</code> etc.) are
available, unlike previous libstdc++ versions, but inclusion
generates a warning that you are using deprecated headers.
</p><p>This compatibility layer is constructed by including the
standard C++ headers, and injecting any items in
<code class="code">std::</code> into the global namespace.
</p><p>For those of you new to ISO C++ (welcome, time travelers!), no,
that isn't a typo. Yes, the headers really have new names.
Marshall Cline's C++ FAQ Lite has a good explanation in <a class="ulink" href="http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.4" target="_top">item
[27.4]</a>.
</p><p> Some include adjustment may be required. What follows is an
autoconf test that defines <code class="code">PRE_STDCXX_HEADERS</code> when they
exist.</p><pre class="programlisting">
# AC_HEADER_PRE_STDCXX
AC_DEFUN([AC_HEADER_PRE_STDCXX], [
AC_CACHE_CHECK(for pre-ISO C++ include files,
ac_cv_cxx_pre_stdcxx,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -Wno-deprecated"
# Omit defalloc.h, as compilation with newer compilers is problematic.
AC_TRY_COMPILE([
#include &lt;new.h&gt;
#include &lt;iterator.h&gt;
#include &lt;alloc.h&gt;
#include &lt;set.h&gt;
#include &lt;hashtable.h&gt;
#include &lt;hash_set.h&gt;
#include &lt;fstream.h&gt;
#include &lt;tempbuf.h&gt;
#include &lt;istream.h&gt;
#include &lt;bvector.h&gt;
#include &lt;stack.h&gt;
#include &lt;rope.h&gt;
#include &lt;complex.h&gt;
#include &lt;ostream.h&gt;
#include &lt;heap.h&gt;
#include &lt;iostream.h&gt;
#include &lt;function.h&gt;
#include &lt;multimap.h&gt;
#include &lt;pair.h&gt;
#include &lt;stream.h&gt;
#include &lt;iomanip.h&gt;
#include &lt;slist.h&gt;
#include &lt;tree.h&gt;
#include &lt;vector.h&gt;
#include &lt;deque.h&gt;
#include &lt;multiset.h&gt;
#include &lt;list.h&gt;
#include &lt;map.h&gt;
#include &lt;algobase.h&gt;
#include &lt;hash_map.h&gt;
#include &lt;algo.h&gt;
#include &lt;queue.h&gt;
#include &lt;streambuf.h&gt;
],,
ac_cv_cxx_pre_stdcxx=yes, ac_cv_cxx_pre_stdcxx=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_pre_stdcxx" = yes; then
AC_DEFINE(PRE_STDCXX_HEADERS,,[Define if pre-ISO C++ header files are present. ])
fi
])
</pre><p>Porting between pre-ISO headers and ISO headers is simple: headers
like <code class="filename">vector.h</code> can be replaced with <code class="filename">vector</code> and a using
directive <code class="code">using namespace std;</code> can be put at the global
scope. This should be enough to get this code compiling, assuming the
other usage is correct.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id516213"></a>Extension headers hash_map, hash_set moved to ext or backwards</h4></div></div></div><p>At this time most of the features of the SGI STL extension have been
replaced by standardized libraries.
In particular, the unordered_map and unordered_set containers of TR1
are suitable replacement for the non-standard hash_map and hash_set
containers in the SGI STL.
</p><p> Header files <code class="filename">hash_map</code> and <code class="filename">hash_set</code> moved
to <code class="filename">ext/hash_map</code> and <code class="filename">ext/hash_set</code>,
respectively. At the same time, all types in these files are enclosed
in <code class="code">namespace __gnu_cxx</code>. Later versions move deprecate
these files, and suggest using TR1's <code class="filename">unordered_map</code>
and <code class="filename">unordered_set</code> instead.
</p><p>The extensions are no longer in the global or <code class="code">std</code>
namespaces, instead they are declared in the <code class="code">__gnu_cxx</code>
namespace. For maximum portability, consider defining a namespace
alias to use to talk about extensions, e.g.:
</p><pre class="programlisting">
#ifdef __GNUC__
#if __GNUC__ &lt; 3
#include &lt;hash_map.h&gt;
namespace extension { using ::hash_map; }; // inherit globals
#else
#include &lt;backward/hash_map&gt;
#if __GNUC__ == 3 &amp;&amp; __GNUC_MINOR__ == 0
namespace extension = std; // GCC 3.0
#else
namespace extension = ::__gnu_cxx; // GCC 3.1 and later
#endif
#endif
#else // ... there are other compilers, right?
namespace extension = std;
#endif
extension::hash_map&lt;int,int&gt; my_map;
</pre><p>This is a bit cleaner than defining typedefs for all the
instantiations you might need.
</p><p>The following autoconf tests check for working HP/SGI hash containers.
</p><pre class="programlisting">
# AC_HEADER_EXT_HASH_MAP
AC_DEFUN([AC_HEADER_EXT_HASH_MAP], [
AC_CACHE_CHECK(for ext/hash_map,
ac_cv_cxx_ext_hash_map,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -Werror"
AC_TRY_COMPILE([#include &lt;ext/hash_map&gt;], [using __gnu_cxx::hash_map;],
ac_cv_cxx_ext_hash_map=yes, ac_cv_cxx_ext_hash_map=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_ext_hash_map" = yes; then
AC_DEFINE(HAVE_EXT_HASH_MAP,,[Define if ext/hash_map is present. ])
fi
])
</pre><pre class="programlisting">
# AC_HEADER_EXT_HASH_SET
AC_DEFUN([AC_HEADER_EXT_HASH_SET], [
AC_CACHE_CHECK(for ext/hash_set,
ac_cv_cxx_ext_hash_set,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -Werror"
AC_TRY_COMPILE([#include &lt;ext/hash_set&gt;], [using __gnu_cxx::hash_set;],
ac_cv_cxx_ext_hash_set=yes, ac_cv_cxx_ext_hash_set=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_ext_hash_set" = yes; then
AC_DEFINE(HAVE_EXT_HASH_SET,,[Define if ext/hash_set is present. ])
fi
])
</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id516316"></a>No <code class="code">ios::nocreate/ios::noreplace</code>.
</h4></div></div></div><p> The existence of <code class="code">ios::nocreate</code> being used for
input-streams has been confirmed, most probably because the author
thought it would be more correct to specify nocreate explicitly. So
it can be left out for input-streams.
</p><p>For output streams, “<span class="quote">nocreate</span>” is probably the default,
unless you specify <code class="code">std::ios::trunc</code> ? To be safe, you can
open the file for reading, check if it has been opened, and then
decide whether you want to create/replace or not. To my knowledge,
even older implementations support <code class="code">app</code>, <code class="code">ate</code>
and <code class="code">trunc</code> (except for <code class="code">app</code> ?).
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id516364"></a>
No <code class="code">stream::attach(int fd)</code>
</h4></div></div></div><p>
Phil Edwards writes: It was considered and rejected for the ISO
standard. Not all environments use file descriptors. Of those
that do, not all of them use integers to represent them.
</p><p>
For a portable solution (among systems which use
filedescriptors), you need to implement a subclass of
<code class="code">std::streambuf</code> (or
<code class="code">std::basic_streambuf&lt;..&gt;</code>) which opens a file
given a descriptor, and then pass an instance of this to the
stream-constructor.
</p><p>
An extension is available that implements this.
<code class="filename">ext/stdio_filebuf.h</code> contains a derived class called
<a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/class____gnu__cxx_1_1stdio__filebuf.html" target="_top"><code class="code">__gnu_cxx::stdio_filebuf</code></a>.
This class can be constructed from a C <code class="code">FILE*</code> or a file
descriptor, and provides the <code class="code">fd()</code> function.
</p><p>
For another example of this, refer to
<a class="ulink" href="http://www.josuttis.com/cppcode/fdstream.html" target="_top">fdstream example</a>
by Nicolai Josuttis.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id516428"></a>
Support for C++98 dialect.
</h4></div></div></div><p>Check for complete library coverage of the C++1998/2003 standard.
</p><pre class="programlisting">
# AC_HEADER_STDCXX_98
AC_DEFUN([AC_HEADER_STDCXX_98], [
AC_CACHE_CHECK(for ISO C++ 98 include files,
ac_cv_cxx_stdcxx_98,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([
#include &lt;cassert&gt;
#include &lt;cctype&gt;
#include &lt;cerrno&gt;
#include &lt;cfloat&gt;
#include &lt;ciso646&gt;
#include &lt;climits&gt;
#include &lt;clocale&gt;
#include &lt;cmath&gt;
#include &lt;csetjmp&gt;
#include &lt;csignal&gt;
#include &lt;cstdarg&gt;
#include &lt;cstddef&gt;
#include &lt;cstdio&gt;
#include &lt;cstdlib&gt;
#include &lt;cstring&gt;
#include &lt;ctime&gt;
#include &lt;algorithm&gt;
#include &lt;bitset&gt;
#include &lt;complex&gt;
#include &lt;deque&gt;
#include &lt;exception&gt;
#include &lt;fstream&gt;
#include &lt;functional&gt;
#include &lt;iomanip&gt;
#include &lt;ios&gt;
#include &lt;iosfwd&gt;
#include &lt;iostream&gt;
#include &lt;istream&gt;
#include &lt;iterator&gt;
#include &lt;limits&gt;
#include &lt;list&gt;
#include &lt;locale&gt;
#include &lt;map&gt;
#include &lt;memory&gt;
#include &lt;new&gt;
#include &lt;numeric&gt;
#include &lt;ostream&gt;
#include &lt;queue&gt;
#include &lt;set&gt;
#include &lt;sstream&gt;
#include &lt;stack&gt;
#include &lt;stdexcept&gt;
#include &lt;streambuf&gt;
#include &lt;string&gt;
#include &lt;typeinfo&gt;
#include &lt;utility&gt;
#include &lt;valarray&gt;
#include &lt;vector&gt;
],,
ac_cv_cxx_stdcxx_98=yes, ac_cv_cxx_stdcxx_98=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_stdcxx_98" = yes; then
AC_DEFINE(STDCXX_98_HEADERS,,[Define if ISO C++ 1998 header files are present. ])
fi
])
</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id516455"></a>
Support for C++TR1 dialect.
</h4></div></div></div><p>Check for library coverage of the TR1 standard.
</p><pre class="programlisting">
# AC_HEADER_STDCXX_TR1
AC_DEFUN([AC_HEADER_STDCXX_TR1], [
AC_CACHE_CHECK(for ISO C++ TR1 include files,
ac_cv_cxx_stdcxx_tr1,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([
#include &lt;tr1/array&gt;
#include &lt;tr1/ccomplex&gt;
#include &lt;tr1/cctype&gt;
#include &lt;tr1/cfenv&gt;
#include &lt;tr1/cfloat&gt;
#include &lt;tr1/cinttypes&gt;
#include &lt;tr1/climits&gt;
#include &lt;tr1/cmath&gt;
#include &lt;tr1/complex&gt;
#include &lt;tr1/cstdarg&gt;
#include &lt;tr1/cstdbool&gt;
#include &lt;tr1/cstdint&gt;
#include &lt;tr1/cstdio&gt;
#include &lt;tr1/cstdlib&gt;
#include &lt;tr1/ctgmath&gt;
#include &lt;tr1/ctime&gt;
#include &lt;tr1/cwchar&gt;
#include &lt;tr1/cwctype&gt;
#include &lt;tr1/functional&gt;
#include &lt;tr1/memory&gt;
#include &lt;tr1/random&gt;
#include &lt;tr1/regex&gt;
#include &lt;tr1/tuple&gt;
#include &lt;tr1/type_traits&gt;
#include &lt;tr1/unordered_set&gt;
#include &lt;tr1/unordered_map&gt;
#include &lt;tr1/utility&gt;
],,
ac_cv_cxx_stdcxx_tr1=yes, ac_cv_cxx_stdcxx_tr1=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_stdcxx_tr1" = yes; then
AC_DEFINE(STDCXX_TR1_HEADERS,,[Define if ISO C++ TR1 header files are present. ])
fi
])
</pre><p>An alternative is to check just for specific TR1 includes, such as &lt;unordered_map&gt; and &lt;unordered_set&gt;.
</p><pre class="programlisting">
# AC_HEADER_TR1_UNORDERED_MAP
AC_DEFUN([AC_HEADER_TR1_UNORDERED_MAP], [
AC_CACHE_CHECK(for tr1/unordered_map,
ac_cv_cxx_tr1_unordered_map,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([#include &lt;tr1/unordered_map&gt;], [using std::tr1::unordered_map;],
ac_cv_cxx_tr1_unordered_map=yes, ac_cv_cxx_tr1_unordered_map=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_tr1_unordered_map" = yes; then
AC_DEFINE(HAVE_TR1_UNORDERED_MAP,,[Define if tr1/unordered_map is present. ])
fi
])
</pre><pre class="programlisting">
# AC_HEADER_TR1_UNORDERED_SET
AC_DEFUN([AC_HEADER_TR1_UNORDERED_SET], [
AC_CACHE_CHECK(for tr1/unordered_set,
ac_cv_cxx_tr1_unordered_set,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([#include &lt;tr1/unordered_set&gt;], [using std::tr1::unordered_set;],
ac_cv_cxx_tr1_unordered_set=yes, ac_cv_cxx_tr1_unordered_set=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_tr1_unordered_set" = yes; then
AC_DEFINE(HAVE_TR1_UNORDERED_SET,,[Define if tr1/unordered_set is present. ])
fi
])
</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id516499"></a>
Support for C++0x dialect.
</h4></div></div></div><p>Check for baseline language coverage in the compiler for the C++0xstandard.
</p><pre class="programlisting">
# AC_COMPILE_STDCXX_OX
AC_DEFUN([AC_COMPILE_STDCXX_0X], [
AC_CACHE_CHECK(if g++ supports C++0x features without additional flags,
ac_cv_cxx_compile_cxx0x_native,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([
template &lt;typename T&gt;
struct check
{
static_assert(sizeof(int) &lt;= sizeof(T), "not big enough");
};
typedef check&lt;check&lt;bool&gt;&gt; right_angle_brackets;
int a;
decltype(a) b;
typedef check&lt;int&gt; check_type;
check_type c;
check_type&amp;&amp; cr = c;],,
ac_cv_cxx_compile_cxx0x_native=yes, ac_cv_cxx_compile_cxx0x_native=no)
AC_LANG_RESTORE
])
AC_CACHE_CHECK(if g++ supports C++0x features with -std=c++0x,
ac_cv_cxx_compile_cxx0x_cxx,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -std=c++0x"
AC_TRY_COMPILE([
template &lt;typename T&gt;
struct check
{
static_assert(sizeof(int) &lt;= sizeof(T), "not big enough");
};
typedef check&lt;check&lt;bool&gt;&gt; right_angle_brackets;
int a;
decltype(a) b;
typedef check&lt;int&gt; check_type;
check_type c;
check_type&amp;&amp; cr = c;],,
ac_cv_cxx_compile_cxx0x_cxx=yes, ac_cv_cxx_compile_cxx0x_cxx=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
AC_CACHE_CHECK(if g++ supports C++0x features with -std=gnu++0x,
ac_cv_cxx_compile_cxx0x_gxx,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([
template &lt;typename T&gt;
struct check
{
static_assert(sizeof(int) &lt;= sizeof(T), "not big enough");
};
typedef check&lt;check&lt;bool&gt;&gt; right_angle_brackets;
int a;
decltype(a) b;
typedef check&lt;int&gt; check_type;
check_type c;
check_type&amp;&amp; cr = c;],,
ac_cv_cxx_compile_cxx0x_gxx=yes, ac_cv_cxx_compile_cxx0x_gxx=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_compile_cxx0x_native" = yes ||
test "$ac_cv_cxx_compile_cxx0x_cxx" = yes ||
test "$ac_cv_cxx_compile_cxx0x_gxx" = yes; then
AC_DEFINE(HAVE_STDCXX_0X,,[Define if g++ supports C++0x features. ])
fi
])
</pre><p>Check for library coverage of the C++0xstandard.
</p><pre class="programlisting">
# AC_HEADER_STDCXX_0X
AC_DEFUN([AC_HEADER_STDCXX_0X], [
AC_CACHE_CHECK(for ISO C++ 0x include files,
ac_cv_cxx_stdcxx_0x,
[AC_REQUIRE([AC_COMPILE_STDCXX_0X])
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([
#include &lt;cassert&gt;
#include &lt;ccomplex&gt;
#include &lt;cctype&gt;
#include &lt;cerrno&gt;
#include &lt;cfenv&gt;
#include &lt;cfloat&gt;
#include &lt;cinttypes&gt;
#include &lt;ciso646&gt;
#include &lt;climits&gt;
#include &lt;clocale&gt;
#include &lt;cmath&gt;
#include &lt;csetjmp&gt;
#include &lt;csignal&gt;
#include &lt;cstdarg&gt;
#include &lt;cstdbool&gt;
#include &lt;cstddef&gt;
#include &lt;cstdint&gt;
#include &lt;cstdio&gt;
#include &lt;cstdlib&gt;
#include &lt;cstring&gt;
#include &lt;ctgmath&gt;
#include &lt;ctime&gt;
#include &lt;cwchar&gt;
#include &lt;cwctype&gt;
#include &lt;algorithm&gt;
#include &lt;array&gt;
#include &lt;bitset&gt;
#include &lt;complex&gt;
#include &lt;deque&gt;
#include &lt;exception&gt;
#include &lt;fstream&gt;
#include &lt;functional&gt;
#include &lt;iomanip&gt;
#include &lt;ios&gt;
#include &lt;iosfwd&gt;
#include &lt;iostream&gt;
#include &lt;istream&gt;
#include &lt;iterator&gt;
#include &lt;limits&gt;
#include &lt;list&gt;
#include &lt;locale&gt;
#include &lt;map&gt;
#include &lt;memory&gt;
#include &lt;new&gt;
#include &lt;numeric&gt;
#include &lt;ostream&gt;
#include &lt;queue&gt;
#include &lt;random&gt;
#include &lt;regex&gt;
#include &lt;set&gt;
#include &lt;sstream&gt;
#include &lt;stack&gt;
#include &lt;stdexcept&gt;
#include &lt;streambuf&gt;
#include &lt;string&gt;
#include &lt;tuple&gt;
#include &lt;typeinfo&gt;
#include &lt;type_traits&gt;
#include &lt;unordered_map&gt;
#include &lt;unordered_set&gt;
#include &lt;utility&gt;
#include &lt;valarray&gt;
#include &lt;vector&gt;
],,
ac_cv_cxx_stdcxx_0x=yes, ac_cv_cxx_stdcxx_0x=no)
AC_LANG_RESTORE
CXXFLAGS="$ac_save_CXXFLAGS"
])
if test "$ac_cv_cxx_stdcxx_0x" = yes; then
AC_DEFINE(STDCXX_0X_HEADERS,,[Define if ISO C++ 0x header files are present. ])
fi
])
</pre><p>As is the case for TR1 support, these autoconf macros can be made for a finer-grained, per-header-file check. For &lt;unordered_map&gt;
</p><pre class="programlisting">
# AC_HEADER_UNORDERED_MAP
AC_DEFUN([AC_HEADER_UNORDERED_MAP], [
AC_CACHE_CHECK(for unordered_map,
ac_cv_cxx_unordered_map,
[AC_REQUIRE([AC_COMPILE_STDCXX_0X])
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([#include &lt;unordered_map&gt;], [using std::unordered_map;],
ac_cv_cxx_unordered_map=yes, ac_cv_cxx_unordered_map=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_unordered_map" = yes; then
AC_DEFINE(HAVE_UNORDERED_MAP,,[Define if unordered_map is present. ])
fi
])
</pre><pre class="programlisting">
# AC_HEADER_UNORDERED_SET
AC_DEFUN([AC_HEADER_UNORDERED_SET], [
AC_CACHE_CHECK(for unordered_set,
ac_cv_cxx_unordered_set,
[AC_REQUIRE([AC_COMPILE_STDCXX_0X])
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([#include &lt;unordered_set&gt;], [using std::unordered_set;],
ac_cv_cxx_unordered_set=yes, ac_cv_cxx_unordered_set=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_unordered_set" = yes; then
AC_DEFINE(HAVE_UNORDERED_SET,,[Define if unordered_set is present. ])
fi
])
</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id437068"></a>
Container::iterator_type is not necessarily Container::value_type*
</h4></div></div></div><p>
This is a change in behavior from the previous version. Now, most
<span class="type">iterator_type</span> typedefs in container classes are POD
objects, not <span class="type">value_type</span> pointers.
</p></div></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id437100"></a><p>[<abbr class="abbrev">
kegel41
</abbr>] <span class="title"><i>
Migrating to GCC 4.1
</i>. </span><span class="author"><span class="firstname">Dan</span> <span class="surname">Kegel</span>. </span><span class="biblioid">
<a class="ulink" href="http://www.kegel.com/gcc/gcc4.html" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id437132"></a><p>[<abbr class="abbrev">
kegel41
</abbr>] <span class="title"><i>
Building the Whole Debian Archive with GCC 4.1: A Summary
</i>. </span><span class="author"><span class="firstname">Martin</span> <span class="surname">Michlmayr</span>. </span><span class="biblioid">
<a class="ulink" href="http://lists.debian.org/debian-gcc/2006/03/msg00405.html" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id437165"></a><p>[<abbr class="abbrev">
lbl32
</abbr>] <span class="title"><i>
Migration guide for GCC-3.2
</i>. </span><span class="biblioid">
<a class="ulink" href="http://annwm.lbl.gov/~leggett/Atlas/gcc-3.2.html" target="_top">
</a>
. </span></p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="api.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_porting.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="appendix_free.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">API Evolution and Deprecation History </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix C. Free Software Needs Free Documentation</td></tr></table></div></body></html>

340
libstdc++-v3/doc/html/manual/bitmap_allocator.html Normal file
View File

@ -0,0 +1,340 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>bitmap_allocator</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; allocator&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt12ch32.html" title="Chapter 32. Allocators" /><link rel="prev" href="bk01pt12ch32.html" title="Chapter 32. Allocators" /><link rel="next" href="bk01pt12ch33.html" title="Chapter 33. Containers" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">bitmap_allocator</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch32.html">Prev</a> </td><th width="60%" align="center">Chapter 32. Allocators</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch33.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.allocator.bitmap"></a>bitmap_allocator</h2></div></div></div><p>
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.bitmap.design"></a>Design</h3></div></div></div><p>
As this name suggests, this allocator uses a bit-map to keep track
of the used and unused memory locations for it's book-keeping
purposes.
</p><p>
This allocator will make use of 1 single bit to keep track of
whether it has been allocated or not. A bit 1 indicates free,
while 0 indicates allocated. This has been done so that you can
easily check a collection of bits for a free block. This kind of
Bitmapped strategy works best for single object allocations, and
with the STL type parameterized allocators, we do not need to
choose any size for the block which will be represented by a
single bit. This will be the size of the parameter around which
the allocator has been parameterized. Thus, close to optimal
performance will result. Hence, this should be used for node based
containers which call the allocate function with an argument of 1.
</p><p>
The bitmapped allocator's internal pool is exponentially growing.
Meaning that internally, the blocks acquired from the Free List
Store will double every time the bitmapped allocator runs out of
memory.
</p><p>
The macro <code class="literal">__GTHREADS</code> decides whether to use
Mutex Protection around every allocation/deallocation. The state
of the macro is picked up automatically from the gthr abstraction
layer.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.bitmap.impl"></a>Implementation</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.free_list_store"></a>Free List Store</h4></div></div></div><p>
The Free List Store (referred to as FLS for the remaining part of this
document) is the Global memory pool that is shared by all instances of
the bitmapped allocator instantiated for any type. This maintains a
sorted order of all free memory blocks given back to it by the
bitmapped allocator, and is also responsible for giving memory to the
bitmapped allocator when it asks for more.
</p><p>
Internally, there is a Free List threshold which indicates the
Maximum number of free lists that the FLS can hold internally
(cache). Currently, this value is set at 64. So, if there are
more than 64 free lists coming in, then some of them will be given
back to the OS using operator delete so that at any given time the
Free List's size does not exceed 64 entries. This is done because
a Binary Search is used to locate an entry in a free list when a
request for memory comes along. Thus, the run-time complexity of
the search would go up given an increasing size, for 64 entries
however, lg(64) == 6 comparisons are enough to locate the correct
free list if it exists.
</p><p>
Suppose the free list size has reached it's threshold, then the
largest block from among those in the list and the new block will
be selected and given back to the OS. This is done because it
reduces external fragmentation, and allows the OS to use the
larger blocks later in an orderly fashion, possibly merging them
later. Also, on some systems, large blocks are obtained via calls
to mmap, so giving them back to free system resources becomes most
important.
</p><p>
The function _S_should_i_give decides the policy that determines
whether the current block of memory should be given to the
allocator for the request that it has made. That's because we may
not always have exact fits for the memory size that the allocator
requests. We do this mainly to prevent external fragmentation at
the cost of a little internal fragmentation. Now, the value of
this internal fragmentation has to be decided by this function. I
can see 3 possibilities right now. Please add more as and when you
find better strategies.
</p><div class="orderedlist"><ol type="1"><li><p>Equal size check. Return true only when the 2 blocks are of equal
size.</p></li><li><p>Difference Threshold: Return true only when the _block_size is
greater than or equal to the _required_size, and if the _BS is &gt; _RS
by a difference of less than some THRESHOLD value, then return true,
else return false. </p></li><li><p>Percentage Threshold. Return true only when the _block_size is
greater than or equal to the _required_size, and if the _BS is &gt; _RS
by a percentage of less than some THRESHOLD value, then return true,
else return false.</p></li></ol></div><p>
Currently, (3) is being used with a value of 36% Maximum wastage per
Super Block.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.super_block"></a>Super Block</h4></div></div></div><p>
A super block is the block of memory acquired from the FLS from
which the bitmap allocator carves out memory for single objects
and satisfies the user's requests. These super blocks come in
sizes that are powers of 2 and multiples of 32
(_Bits_Per_Block). Yes both at the same time! That's because the
next super block acquired will be 2 times the previous one, and
also all super blocks have to be multiples of the _Bits_Per_Block
value.
</p><p>
How does it interact with the free list store?
</p><p>
The super block is contained in the FLS, and the FLS is responsible for
getting / returning Super Bocks to and from the OS using operator new
as defined by the C++ standard.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.super_block_data"></a>Super Block Data Layout</h4></div></div></div><p>
Each Super Block will be of some size that is a multiple of the
number of Bits Per Block. Typically, this value is chosen as
Bits_Per_Byte x sizeof(size_t). On an x86 system, this gives the
figure 8 x 4 = 32. Thus, each Super Block will be of size 32
x Some_Value. This Some_Value is sizeof(value_type). For now, let
it be called 'K'. Thus, finally, Super Block size is 32 x K bytes.
</p><p>
This value of 32 has been chosen because each size_t has 32-bits
and Maximum use of these can be made with such a figure.
</p><p>
Consider a block of size 64 ints. In memory, it would look like this:
(assume a 32-bit system where, size_t is a 32-bit entity).
</p><div class="table"><a id="id510462"></a><p class="title"><b>Table 32.1. Bitmap Allocator Memory Map</b></p><div class="table-contents"><table summary="Bitmap Allocator Memory Map" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left">268</td><td align="left">0</td><td align="left">4294967295</td><td align="left">4294967295</td><td align="left">Data -&gt; Space for 64 ints</td></tr></tbody></table></div></div><br class="table-break" /><p>
The first Column(268) represents the size of the Block in bytes as
seen by the Bitmap Allocator. Internally, a global free list is
used to keep track of the free blocks used and given back by the
bitmap allocator. It is this Free List Store that is responsible
for writing and managing this information. Actually the number of
bytes allocated in this case would be: 4 + 4 + (4x2) + (64x4) =
272 bytes, but the first 4 bytes are an addition by the Free List
Store, so the Bitmap Allocator sees only 268 bytes. These first 4
bytes about which the bitmapped allocator is not aware hold the
value 268.
</p><p>
What do the remaining values represent?</p><p>
The 2nd 4 in the expression is the sizeof(size_t) because the
Bitmapped Allocator maintains a used count for each Super Block,
which is initially set to 0 (as indicated in the diagram). This is
incremented every time a block is removed from this super block
(allocated), and decremented whenever it is given back. So, when
the used count falls to 0, the whole super block will be given
back to the Free List Store.
</p><p>
The value 4294967295 represents the integer corresponding to the bit
representation of all bits set: 11111111111111111111111111111111.
</p><p>
The 3rd 4x2 is size of the bitmap itself, which is the size of 32-bits
x 2,
which is 8-bytes, or 2 x sizeof(size_t).
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.max_wasted"></a>Maximum Wasted Percentage</h4></div></div></div><p>
This has nothing to do with the algorithm per-se,
only with some vales that must be chosen correctly to ensure that the
allocator performs well in a real word scenario, and maintains a good
balance between the memory consumption and the allocation/deallocation
speed.
</p><p>
The formula for calculating the maximum wastage as a percentage:
</p><p>
(32 x k + 1) / (2 x (32 x k + 1 + 32 x c)) x 100.
</p><p>
Where, k =&gt; The constant overhead per node. eg. for list, it is
8 bytes, and for map it is 12 bytes. c =&gt; The size of the
base type on which the map/list is instantiated. Thus, suppose the
type1 is int and type2 is double, they are related by the relation
sizeof(double) == 2*sizeof(int). Thus, all types must have this
double size relation for this formula to work properly.
</p><p>
Plugging-in: For List: k = 8 and c = 4 (int and double), we get:
33.376%
</p><p>
For map/multimap: k = 12, and c = 4 (int and double), we get: 37.524%
</p><p>
Thus, knowing these values, and based on the sizeof(value_type), we may
create a function that returns the Max_Wastage_Percentage for us to use.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.allocate"></a><code class="function">allocate</code></h4></div></div></div><p>
The allocate function is specialized for single object allocation
ONLY. Thus, ONLY if n == 1, will the bitmap_allocator's
specialized algorithm be used. Otherwise, the request is satisfied
directly by calling operator new.
</p><p>
Suppose n == 1, then the allocator does the following:
</p><div class="orderedlist"><ol type="1"><li><p>
Checks to see whether a free block exists somewhere in a region
of memory close to the last satisfied request. If so, then that
block is marked as allocated in the bit map and given to the
user. If not, then (2) is executed.
</p></li><li><p>
Is there a free block anywhere after the current block right
up to the end of the memory that we have? If so, that block is
found, and the same procedure is applied as above, and
returned to the user. If not, then (3) is executed.
</p></li><li><p>
Is there any block in whatever region of memory that we own
free? This is done by checking
</p><div class="itemizedlist"><ul type="disc"><li><p>
The use count for each super block, and if that fails then
</p></li><li><p>
The individual bit-maps for each super block.
</p></li></ul></div><p>
Note: Here we are never touching any of the memory that the
user will be given, and we are confining all memory accesses
to a small region of memory! This helps reduce cache
misses. If this succeeds then we apply the same procedure on
that bit-map as (1), and return that block of memory to the
user. However, if this process fails, then we resort to (4).
</p></li><li><p>
This process involves Refilling the internal exponentially
growing memory pool. The said effect is achieved by calling
_S_refill_pool which does the following:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Gets more memory from the Global Free List of the Required
size.
</p></li><li><p>
Adjusts the size for the next call to itself.
</p></li><li><p>
Writes the appropriate headers in the bit-maps.
</p></li><li><p>
Sets the use count for that super-block just allocated to 0
(zero).
</p></li><li><p>
All of the above accounts to maintaining the basic invariant
for the allocator. If the invariant is maintained, we are
sure that all is well. Now, the same process is applied on
the newly acquired free blocks, which are dispatched
accordingly.
</p></li></ul></div></li></ol></div><p>
Thus, you can clearly see that the allocate function is nothing but a
combination of the next-fit and first-fit algorithm optimized ONLY for
single object allocations.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.deallocate"></a><code class="function">deallocate</code></h4></div></div></div><p>
The deallocate function again is specialized for single objects ONLY.
For all n belonging to &gt; 1, the operator delete is called without
further ado, and the deallocate function returns.
</p><p>
However for n == 1, a series of steps are performed:
</p><div class="orderedlist"><ol type="1"><li><p>
We first need to locate that super-block which holds the memory
location given to us by the user. For that purpose, we maintain
a static variable _S_last_dealloc_index, which holds the index
into the vector of block pairs which indicates the index of the
last super-block from which memory was freed. We use this
strategy in the hope that the user will deallocate memory in a
region close to what he/she deallocated the last time around. If
the check for belongs_to succeeds, then we determine the bit-map
for the given pointer, and locate the index into that bit-map,
and mark that bit as free by setting it.
</p></li><li><p>
If the _S_last_dealloc_index does not point to the memory block
that we're looking for, then we do a linear search on the block
stored in the vector of Block Pairs. This vector in code is
called _S_mem_blocks. When the corresponding super-block is
found, we apply the same procedure as we did for (1) to mark the
block as free in the bit-map.
</p></li></ol></div><p>
Now, whenever a block is freed, the use count of that particular
super block goes down by 1. When this use count hits 0, we remove
that super block from the list of all valid super blocks stored in
the vector. While doing this, we also make sure that the basic
invariant is maintained by making sure that _S_last_request and
_S_last_dealloc_index point to valid locations within the vector.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.questions"></a>Questions</h4></div></div></div><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="bitmap.impl.question.1"></a>1</h5></div></div></div><p>
Q1) The "Data Layout" section is
cryptic. I have no idea of what you are trying to say. Layout of what?
The free-list? Each bitmap? The Super Block?
</p><p>
The layout of a Super Block of a given
size. In the example, a super block of size 32 x 1 is taken. The
general formula for calculating the size of a super block is
32 x sizeof(value_type) x 2^n, where n ranges from 0 to 32 for 32-bit
systems.
</p></div><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="bitmap.impl.question.2"></a>2</h5></div></div></div><p>
And since I just mentioned the
term `each bitmap', what in the world is meant by it? What does each
bitmap manage? How does it relate to the super block? Is the Super
Block a bitmap as well?
</p><p>
Each bitmap is part of a Super Block which is made up of 3 parts
as I have mentioned earlier. Re-iterating, 1. The use count,
2. The bit-map for that Super Block. 3. The actual memory that
will be eventually given to the user. Each bitmap is a multiple
of 32 in size. If there are 32 x (2^3) blocks of single objects
to be given, there will be '32 x (2^3)' bits present. Each 32
bits managing the allocated / free status for 32 blocks. Since
each size_t contains 32-bits, one size_t can manage up to 32
blocks' status. Each bit-map is made up of a number of size_t,
whose exact number for a super-block of a given size I have just
mentioned.
</p></div><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="bitmap.impl.question.3"></a>3</h5></div></div></div><p>
How do the allocate and deallocate functions work in regard to
bitmaps?
</p><p>
The allocate and deallocate functions manipulate the bitmaps and
have nothing to do with the memory that is given to the user. As
I have earlier mentioned, a 1 in the bitmap's bit field
indicates free, while a 0 indicates allocated. This lets us
check 32 bits at a time to check whether there is at lease one
free block in those 32 blocks by testing for equality with
(0). Now, the allocate function will given a memory block find
the corresponding bit in the bitmap, and will reset it (i.e.,
make it re-set (0)). And when the deallocate function is called,
it will again set that bit after locating it to indicate that
that particular block corresponding to this bit in the bit-map
is not being used by anyone, and may be used to satisfy future
requests.
</p><p>
e.g.: Consider a bit-map of 64-bits as represented below:
1111111111111111111111111111111111111111111111111111111111111111
</p><p>
Now, when the first request for allocation of a single object
comes along, the first block in address order is returned. And
since the bit-maps in the reverse order to that of the address
order, the last bit (LSB if the bit-map is considered as a
binary word of 64-bits) is re-set to 0.
</p><p>
The bit-map now looks like this:
1111111111111111111111111111111111111111111111111111111111111110
</p></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.locality"></a>Locality</h4></div></div></div><p>
Another issue would be whether to keep the all bitmaps in a
separate area in memory, or to keep them near the actual blocks
that will be given out or allocated for the client. After some
testing, I've decided to keep these bitmaps close to the actual
blocks. This will help in 2 ways.
</p><div class="orderedlist"><ol type="1"><li><p>Constant time access for the bitmap themselves, since no kind of
look up will be needed to find the correct bitmap list or it's
equivalent.</p></li><li><p>And also this would preserve the cache as far as possible.</p></li></ol></div><p>
So in effect, this kind of an allocator might prove beneficial from a
purely cache point of view. But this allocator has been made to try and
roll out the defects of the node_allocator, wherein the nodes get
skewed about in memory, if they are not returned in the exact reverse
order or in the same order in which they were allocated. Also, the
new_allocator's book keeping overhead is too much for small objects and
single object allocations, though it preserves the locality of blocks
very well when they are returned back to the allocator.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.grow_policy"></a>Overhead and Grow Policy</h4></div></div></div><p>
Expected overhead per block would be 1 bit in memory. Also, once
the address of the free list has been found, the cost for
allocation/deallocation would be negligible, and is supposed to be
constant time. For these very reasons, it is very important to
minimize the linear time costs, which include finding a free list
with a free block while allocating, and finding the corresponding
free list for a block while deallocating. Therefore, I have
decided that the growth of the internal pool for this allocator
will be exponential as compared to linear for
node_allocator. There, linear time works well, because we are
mainly concerned with speed of allocation/deallocation and memory
consumption, whereas here, the allocation/deallocation part does
have some linear/logarithmic complexity components in it. Thus, to
try and minimize them would be a good thing to do at the cost of a
little bit of memory.
</p><p>
Another thing to be noted is the pool size will double every time
the internal pool gets exhausted, and all the free blocks have
been given away. The initial size of the pool would be
sizeof(size_t) x 8 which is the number of bits in an integer,
which can fit exactly in a CPU register. Hence, the term given is
exponential growth of the internal pool.
</p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch32.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt12ch32.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch33.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 32. Allocators </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 33. Containers</td></tr></table></div></body></html>

96
libstdc++-v3/doc/html/manual/bk01apas02.html Normal file
View File

@ -0,0 +1,96 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Directory Layout and Source Conventions</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_contributing.html" title="Appendix A. Contributing" /><link rel="prev" href="appendix_contributing.html" title="Appendix A. Contributing" /><link rel="next" href="bk01apas03.html" title="Coding Style" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Directory Layout and Source Conventions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="appendix_contributing.html">Prev</a> </td><th width="60%" align="center">Appendix A. Contributing</th><td width="20%" align="right"> <a accesskey="n" href="bk01apas03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contrib.organization"></a>Directory Layout and Source Conventions</h2></div></div></div><p>
The unpacked source directory of libstdc++ contains the files
needed to create the GNU C++ Library.
</p><div class="literallayout"><p><br />
It has subdirectories:<br />
<br />
  doc<br />
    Files in HTML and text format that document usage, quirks of the<br />
    implementation, and contributor checklists.<br />
<br />
  include<br />
    All header files for the C++ library are within this directory,<br />
    modulo specific runtime-related files that are in the libsupc++<br />
    directory.<br />
<br />
    include/std<br />
      Files meant to be found by #include &lt;name&gt; directives in<br />
      standard-conforming user programs.  <br />
<br />
    include/c<br />
      Headers intended to directly include standard C headers. <br />
      [NB: this can be enabled via --enable-cheaders=c]<br />
<br />
    include/c_global <br />
      Headers intended to include standard C headers in<br />
      the global namespace, and put select names into the std::<br />
      namespace.  [NB: this is the default, and is the same as<br />
      --enable-cheaders=c_global]<br />
<br />
    include/c_std <br />
      Headers intended to include standard C headers<br />
      already in namespace std, and put select names into the std::<br />
      namespace.  [NB: this is the same as --enable-cheaders=c_std]<br />
<br />
    include/bits<br />
      Files included by standard headers and by other files in<br />
      the bits directory. <br />
<br />
    include/backward<br />
      Headers provided for backward compatibility, such as &lt;iostream.h&gt;.<br />
      They are not used in this library.<br />
<br />
    include/ext<br />
      Headers that define extensions to the standard library.  No<br />
      standard header refers to any of them.<br />
<br />
  scripts<br />
    Scripts that are used during the configure, build, make, or test<br />
    process.<br />
<br />
  src<br />
    Files that are used in constructing the library, but are not<br />
    installed.<br />
<br />
  testsuites/[backward, demangle, ext, performance, thread, 17_* to 27_*]<br />
    Test programs are here, and may be used to begin to exercise the <br />
    library.  Support for "make check" and "make check-install" is<br />
    complete, and runs through all the subdirectories here when this<br />
    command is issued from the build directory.  Please note that<br />
    "make check" requires DejaGNU 1.4 or later to be installed.  Please<br />
    note that "make check-script" calls the script mkcheck, which<br />
    requires bash, and which may need the paths to bash adjusted to<br />
    work properly, as /bin/bash is assumed.<br />
<br />
Other subdirectories contain variant versions of certain files<br />
that are meant to be copied or linked by the configure script.<br />
Currently these are:<br />
<br />
  config/abi<br />
  config/cpu<br />
  config/io<br />
  config/locale<br />
  config/os<br />
<br />
In addition, two subdirectories are convenience libraries:<br />
<br />
  libmath<br />
    Support routines needed for C++ math. Only needed if the<br />
    underlying "C" implementation is non-existent, in particular<br />
    required or optimal long double, long long, and C99 functionality.<br />
<br />
  libsupc++<br />
    Contains the runtime library for C++, including exception<br />
    handling and memory allocation and deallocation, RTTI, terminate<br />
    handlers, etc.<br />
<br />
Note that glibc also has a bits/ subdirectory.  We will either<br />
need to be careful not to collide with names in its bits/<br />
directory; or rename bits to (e.g.) cppbits/.<br />
<br />
In files throughout the system, lines marked with an "XXX" indicate<br />
a bug or incompletely-implemented feature.  Lines marked "XXX MT"<br />
indicate a place that may require attention for multi-thread safety.<br />
  </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="appendix_contributing.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_contributing.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01apas03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Appendix A. Contributing </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Coding Style</td></tr></table></div></body></html>

582
libstdc++-v3/doc/html/manual/bk01apas03.html Normal file
View File

@ -0,0 +1,582 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Coding Style</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_contributing.html" title="Appendix A. Contributing" /><link rel="prev" href="bk01apas02.html" title="Directory Layout and Source Conventions" /><link rel="next" href="bk01apas04.html" title="Documentation Style" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Coding Style</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01apas02.html">Prev</a> </td><th width="60%" align="center">Appendix A. Contributing</th><td width="20%" align="right"> <a accesskey="n" href="bk01apas04.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contrib.coding_style"></a>Coding Style</h2></div></div></div><p>
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="coding_style.bad_identifiers"></a>Bad Itentifiers</h3></div></div></div><p>
Identifiers that conflict and should be avoided.
</p><div class="literallayout"><p><br />
      This is the list of names “<span class="quote">reserved to the<br />
      implementation</span>” that have been claimed by certain<br />
      compilers and system headers of interest, and should not be used<br />
      in the library. It will grow, of course.  We generally are<br />
      interested in names that are not all-caps, except for those like<br />
      "_T"<br />
<br />
      For Solaris:<br />
      _B<br />
      _C<br />
      _L<br />
      _N<br />
      _P<br />
      _S<br />
      _U<br />
      _X<br />
      _E1<br />
      ..<br />
      _E24<br />
<br />
      Irix adds:<br />
      _A<br />
      _G<br />
<br />
      MS adds:<br />
      _T<br />
<br />
      BSD adds:<br />
      __used<br />
      __unused<br />
      __inline<br />
      _Complex<br />
      __istype<br />
      __maskrune<br />
      __tolower<br />
      __toupper<br />
      __wchar_t<br />
      __wint_t<br />
      _res<br />
      _res_ext<br />
      __tg_*<br />
<br />
      For GCC:<br />
<br />
      [Note that this list is out of date. It applies to the old<br />
      name-mangling; in G++ 3.0 and higher a different name-mangling is<br />
      used. In addition, many of the bugs relating to G++ interpreting<br />
      these names as operators have been fixed.]<br />
<br />
      The full set of __* identifiers (combined from gcc/cp/lex.c and<br />
      gcc/cplus-dem.c) that are either old or new, but are definitely <br />
      recognized by the demangler, is:<br />
<br />
      __aa<br />
      __aad<br />
      __ad<br />
      __addr<br />
      __adv<br />
      __aer<br />
      __als<br />
      __alshift<br />
      __amd<br />
      __ami<br />
      __aml<br />
      __amu<br />
      __aor<br />
      __apl<br />
      __array<br />
      __ars<br />
      __arshift<br />
      __as<br />
      __bit_and<br />
      __bit_ior<br />
      __bit_not<br />
      __bit_xor<br />
      __call<br />
      __cl<br />
      __cm<br />
      __cn<br />
      __co<br />
      __component<br />
      __compound<br />
      __cond<br />
      __convert<br />
      __delete<br />
      __dl<br />
      __dv<br />
      __eq<br />
      __er<br />
      __ge<br />
      __gt<br />
      __indirect<br />
      __le<br />
      __ls<br />
      __lt<br />
      __max<br />
      __md<br />
      __method_call<br />
      __mi<br />
      __min<br />
      __minus<br />
      __ml<br />
      __mm<br />
      __mn<br />
      __mult<br />
      __mx<br />
      __ne<br />
      __negate<br />
      __new<br />
      __nop<br />
      __nt<br />
      __nw<br />
      __oo<br />
      __op<br />
      __or<br />
      __pl<br />
      __plus<br />
      __postdecrement<br />
      __postincrement<br />
      __pp<br />
      __pt<br />
      __rf<br />
      __rm<br />
      __rs<br />
      __sz<br />
      __trunc_div<br />
      __trunc_mod<br />
      __truth_andif<br />
      __truth_not<br />
      __truth_orif<br />
      __vc<br />
      __vd<br />
      __vn<br />
<br />
      SGI badnames:<br />
      __builtin_alloca<br />
      __builtin_fsqrt<br />
      __builtin_sqrt<br />
      __builtin_fabs<br />
      __builtin_dabs<br />
      __builtin_cast_f2i<br />
      __builtin_cast_i2f<br />
      __builtin_cast_d2ll<br />
      __builtin_cast_ll2d<br />
      __builtin_copy_dhi2i<br />
      __builtin_copy_i2dhi<br />
      __builtin_copy_dlo2i<br />
      __builtin_copy_i2dlo<br />
      __add_and_fetch<br />
      __sub_and_fetch<br />
      __or_and_fetch<br />
      __xor_and_fetch<br />
      __and_and_fetch<br />
      __nand_and_fetch<br />
      __mpy_and_fetch<br />
      __min_and_fetch<br />
      __max_and_fetch<br />
      __fetch_and_add<br />
      __fetch_and_sub<br />
      __fetch_and_or<br />
      __fetch_and_xor<br />
      __fetch_and_and<br />
      __fetch_and_nand<br />
      __fetch_and_mpy<br />
      __fetch_and_min<br />
      __fetch_and_max<br />
      __lock_test_and_set<br />
      __lock_release<br />
      __lock_acquire<br />
      __compare_and_swap<br />
      __synchronize<br />
      __high_multiply<br />
      __unix<br />
      __sgi<br />
      __linux__<br />
      __i386__<br />
      __i486__<br />
      __cplusplus<br />
      __embedded_cplusplus<br />
      // long double conversion members mangled as __opr<br />
      // http://gcc.gnu.org/ml/libstdc++/1999-q4/msg00060.html<br />
      _opr<br />
    </p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="coding_style.example"></a>By Example</h3></div></div></div><div class="literallayout"><p><br />
      This library is written to appropriate C++ coding standards. As such,<br />
      it is intended to precede the recommendations of the GNU Coding<br />
      Standard, which can be referenced in full here:<br />
<br />
      http://www.gnu.org/prep/standards/standards.html#Formatting<br />
<br />
      The rest of this is also interesting reading, but skip the "Design<br />
      Advice" part.<br />
<br />
      The GCC coding conventions are here, and are also useful:<br />
      http://gcc.gnu.org/codingconventions.html<br />
<br />
      In addition, because it doesn't seem to be stated explicitly anywhere<br />
      else, there is an 80 column source limit.<br />
<br />
      ChangeLog entries for member functions should use the<br />
      classname::member function name syntax as follows:<br />
<br />
      1999-04-15  Dennis Ritchie  &lt;dr@att.com&gt;<br />
<br />
      * src/basic_file.cc (__basic_file::open): Fix thinko in<br />
      _G_HAVE_IO_FILE_OPEN bits.<br />
<br />
      Notable areas of divergence from what may be previous local practice<br />
      (particularly for GNU C) include:<br />
<br />
      01. Pointers and references<br />
      char* p = "flop";<br />
      char&amp; c = *p;<br />
      -NOT-<br />
      char *p = "flop";  // wrong<br />
      char &amp;c = *p;      // wrong<br />
      <br />
      Reason: In C++, definitions are mixed with executable code. Here,       <br />
      p is being initialized, not *p. This is near-universal<br />
      practice among C++ programmers; it is normal for C hackers<br />
      to switch spontaneously as they gain experience.<br />
<br />
      02. Operator names and parentheses<br />
      operator==(type)<br />
      -NOT-<br />
      operator == (type)  // wrong<br />
      <br />
      Reason: The == is part of the function name. Separating<br />
      it makes the declaration look like an expression. <br />
<br />
      03. Function names and parentheses<br />
      void mangle()<br />
      -NOT-<br />
      void mangle ()  // wrong<br />
<br />
      Reason: no space before parentheses (except after a control-flow<br />
      keyword) is near-universal practice for C++. It identifies the<br />
      parentheses as the function-call operator or declarator, as <br />
      opposed to an expression or other overloaded use of parentheses.<br />
<br />
      04. Template function indentation<br />
      template&lt;typename T&gt;<br />
      void <br />
      template_function(args)<br />
      { }<br />
      -NOT-<br />
      template&lt;class T&gt;<br />
      void template_function(args) {};<br />
      <br />
      Reason: In class definitions, without indentation whitespace is<br />
      needed both above and below the declaration to distinguish<br />
      it visually from other members. (Also, re: "typename"<br />
      rather than "class".)  T often could be int, which is <br />
      not a class. ("class", here, is an anachronism.)<br />
<br />
      05. Template class indentation<br />
      template&lt;typename _CharT, typename _Traits&gt;<br />
      class basic_ios : public ios_base<br />
      {<br />
      public:<br />
      // Types:<br />
      };<br />
      -NOT-<br />
      template&lt;class _CharT, class _Traits&gt;<br />
      class basic_ios : public ios_base<br />
      {<br />
      public:<br />
      // Types:<br />
      };<br />
      -NOT-<br />
      template&lt;class _CharT, class _Traits&gt;<br />
      class basic_ios : public ios_base<br />
      {<br />
      public:<br />
      // Types:<br />
      };<br />
<br />
      06. Enumerators<br />
      enum<br />
      {<br />
      space = _ISspace,<br />
      print = _ISprint,<br />
      cntrl = _IScntrl<br />
      };<br />
      -NOT-<br />
      enum { space = _ISspace, print = _ISprint, cntrl = _IScntrl };<br />
<br />
      07. Member initialization lists<br />
      All one line, separate from class name.<br />
<br />
      gribble::gribble() <br />
      : _M_private_data(0), _M_more_stuff(0), _M_helper(0);<br />
      { }<br />
      -NOT-<br />
      gribble::gribble() : _M_private_data(0), _M_more_stuff(0), _M_helper(0);<br />
      { }<br />
<br />
      08. Try/Catch blocks<br />
      try <br />
      {<br />
      //<br />
      }   <br />
      catch (...)<br />
      {<br />
      //<br />
      }   <br />
      -NOT-<br />
      try {<br />
      // <br />
      } catch(...) { <br />
      //<br />
      }<br />
<br />
      09. Member functions declarations and definitions<br />
      Keywords such as extern, static, export, explicit, inline, etc<br />
      go on the line above the function name. Thus<br />
<br />
      virtual int   <br />
      foo()<br />
      -NOT-<br />
      virtual int foo()<br />
<br />
      Reason: GNU coding conventions dictate return types for functions<br />
      are on a separate line than the function name and parameter list<br />
      for definitions. For C++, where we have member functions that can<br />
      be either inline definitions or declarations, keeping to this<br />
      standard allows all member function names for a given class to be<br />
      aligned to the same margin, increasing readibility.<br />
<br />
<br />
      10. Invocation of member functions with "this-&gt;"<br />
      For non-uglified names, use this-&gt;name to call the function.<br />
<br />
      this-&gt;sync()<br />
      -NOT-<br />
      sync()<br />
<br />
      Reason: Koenig lookup.<br />
<br />
      11. Namespaces<br />
      namespace std<br />
      {<br />
      blah blah blah;<br />
      } // namespace std<br />
<br />
      -NOT-<br />
<br />
      namespace std {<br />
      blah blah blah;<br />
      } // namespace std<br />
<br />
      12. Spacing under protected and private in class declarations:<br />
      space above, none below<br />
      ie<br />
<br />
      public:<br />
      int foo;<br />
<br />
      -NOT-<br />
      public:<br />
      <br />
      int foo;<br />
<br />
      13. Spacing WRT return statements.<br />
      no extra spacing before returns, no parenthesis<br />
      ie<br />
<br />
      }<br />
      return __ret;<br />
<br />
      -NOT-<br />
      }<br />
<br />
      return __ret;<br />
<br />
      -NOT-<br />
<br />
      }<br />
      return (__ret);<br />
<br />
<br />
      14. Location of global variables.<br />
      All global variables of class type, whether in the "user visable"<br />
      space (e.g., cin) or the implementation namespace, must be defined<br />
      as a character array with the appropriate alignment and then later<br />
      re-initialized to the correct value.<br />
<br />
      This is due to startup issues on certain platforms, such as AIX.<br />
      For more explanation and examples, see src/globals.cc. All such<br />
      variables should be contained in that file, for simplicity.<br />
<br />
      15. Exception abstractions<br />
      Use the exception abstractions found in functexcept.h, which allow<br />
      C++ programmers to use this library with -fno-exceptions. (Even if<br />
      that is rarely advisable, it's a necessary evil for backwards<br />
      compatibility.)<br />
<br />
      16. Exception error messages<br />
      All start with the name of the function where the exception is<br />
      thrown, and then (optional) descriptive text is added. Example:<br />
<br />
      __throw_logic_error(__N("basic_string::_S_construct NULL not valid"));<br />
<br />
      Reason: The verbose terminate handler prints out exception::what(),<br />
      as well as the typeinfo for the thrown exception. As this is the<br />
      default terminate handler, by putting location info into the<br />
      exception string, a very useful error message is printed out for<br />
      uncaught exceptions. So useful, in fact, that non-programmers can<br />
      give useful error messages, and programmers can intelligently<br />
      speculate what went wrong without even using a debugger.<br />
<br />
      17. The doxygen style guide to comments is a separate document,<br />
      see index.<br />
<br />
      The library currently has a mixture of GNU-C and modern C++ coding<br />
      styles. The GNU C usages will be combed out gradually.<br />
<br />
      Name patterns:<br />
<br />
      For nonstandard names appearing in Standard headers, we are constrained <br />
      to use names that begin with underscores. This is called "uglification".<br />
      The convention is:<br />
<br />
      Local and argument names:  __[a-z].*<br />
<br />
      Examples:  __count  __ix  __s1  <br />
<br />
      Type names and template formal-argument names: _[A-Z][^_].*<br />
<br />
      Examples:  _Helper  _CharT  _N <br />
<br />
      Member data and function names: _M_.*<br />
<br />
      Examples:  _M_num_elements  _M_initialize ()<br />
<br />
      Static data members, constants, and enumerations: _S_.*<br />
<br />
      Examples: _S_max_elements  _S_default_value<br />
<br />
      Don't use names in the same scope that differ only in the prefix, <br />
      e.g. _S_top and _M_top. See BADNAMES for a list of forbidden names.<br />
      (The most tempting of these seem to be and "_T" and "__sz".)<br />
<br />
      Names must never have "__" internally; it would confuse name<br />
      unmanglers on some targets. Also, never use "__[0-9]", same reason.<br />
<br />
      --------------------------<br />
<br />
      [BY EXAMPLE]<br />
      <br />
      #ifndef  _HEADER_<br />
      #define  _HEADER_ 1<br />
<br />
      namespace std<br />
      {<br />
      class gribble<br />
      {<br />
      public:<br />
      gribble() throw();<br />
<br />
      gribble(const gribble&amp;);<br />
<br />
      explicit <br />
      gribble(int __howmany);<br />
<br />
      gribble&amp; <br />
      operator=(const gribble&amp;);<br />
<br />
      virtual <br />
      ~gribble() throw ();<br />
<br />
      // Start with a capital letter, end with a period.<br />
      inline void  <br />
      public_member(const char* __arg) const;<br />
<br />
      // In-class function definitions should be restricted to one-liners.<br />
      int <br />
      one_line() { return 0 }<br />
<br />
      int <br />
      two_lines(const char* arg) <br />
      { return strchr(arg, 'a'); }<br />
<br />
      inline int <br />
      three_lines();  // inline, but defined below.<br />
<br />
      // Note indentation.<br />
      template&lt;typename _Formal_argument&gt;<br />
      void <br />
      public_template() const throw();<br />
<br />
      template&lt;typename _Iterator&gt;<br />
      void <br />
      other_template();<br />
<br />
      private:<br />
      class _Helper;<br />
<br />
      int _M_private_data;<br />
      int _M_more_stuff;<br />
      _Helper* _M_helper;<br />
      int _M_private_function();<br />
<br />
      enum _Enum <br />
      { <br />
      _S_one, <br />
      _S_two <br />
      };<br />
<br />
      static void <br />
      _S_initialize_library();<br />
      };<br />
<br />
      // More-or-less-standard language features described by lack, not presence.<br />
      # ifndef _G_NO_LONGLONG<br />
      extern long long _G_global_with_a_good_long_name;  // avoid globals!<br />
      # endif<br />
<br />
      // Avoid in-class inline definitions, define separately;<br />
      // likewise for member class definitions:<br />
      inline int<br />
      gribble::public_member() const<br />
      { int __local = 0; return __local; }<br />
<br />
      class gribble::_Helper<br />
      {<br />
      int _M_stuff;<br />
<br />
      friend class gribble;<br />
      };<br />
      }<br />
<br />
      // Names beginning with "__": only for arguments and<br />
      //   local variables; never use "__" in a type name, or<br />
      //   within any name; never use "__[0-9]".<br />
<br />
      #endif /* _HEADER_ */<br />
<br />
<br />
      namespace std <br />
      {<br />
      template&lt;typename T&gt;  // notice: "typename", not "class", no space<br />
      long_return_value_type&lt;with_many, args&gt;  <br />
      function_name(char* pointer,               // "char *pointer" is wrong.<br />
      char* argument, <br />
      const Reference&amp; ref)<br />
      {<br />
      // int a_local;  /* wrong; see below. */<br />
      if (test) <br />
      { <br />
      nested code <br />
      }<br />
      <br />
      int a_local = 0;  // declare variable at first use.<br />
<br />
      //  char a, b, *p;   /* wrong */<br />
      char a = 'a';<br />
      char b = a + 1;<br />
      char* c = "abc";  // each variable goes on its own line, always.<br />
<br />
      // except maybe here...<br />
      for (unsigned i = 0, mask = 1; mask; ++i, mask &lt;&lt;= 1) {<br />
      // ...<br />
      }<br />
      }<br />
      <br />
      gribble::gribble()<br />
      : _M_private_data(0), _M_more_stuff(0), _M_helper(0);<br />
      { }<br />
<br />
      inline int <br />
      gribble::three_lines()<br />
      {<br />
      // doesn't fit in one line.<br />
      }<br />
      } // namespace std<br />
    </p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01apas02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_contributing.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01apas04.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Directory Layout and Source Conventions </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Documentation Style</td></tr></table></div></body></html>

263
libstdc++-v3/doc/html/manual/bk01apas04.html Normal file
View File

@ -0,0 +1,263 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Documentation Style</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_contributing.html" title="Appendix A. Contributing" /><link rel="prev" href="bk01apas03.html" title="Coding Style" /><link rel="next" href="bk01apas05.html" title="Design Notes" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Documentation Style</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01apas03.html">Prev</a> </td><th width="60%" align="center">Appendix A. Contributing</th><td width="20%" align="right"> <a accesskey="n" href="bk01apas05.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contrib.doc_style"></a>Documentation Style</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="doc_style.doxygen"></a>Doxygen</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="doxygen.prereq"></a>Prerequisites</h4></div></div></div><p>
Prerequisite tools are Bash 2.x,
<a class="ulink" href="http://www.doxygen.org/" target="_top">Doxygen</a>, and
the <a class="ulink" href="http://www.gnu.org/software/coreutils/" target="_top">GNU
coreutils</a>. (GNU versions of find, xargs, and possibly
sed and grep are used, just because the GNU versions make
things very easy.)
</p><p>
To generate the pretty pictures and hierarchy
graphs, the
<a class="ulink" href="http://www.research.att.com/sw/tools/graphviz/download.html" target="_top">Graphviz</a>
package will need to be installed.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="doxygen.rules"></a>Generating the Doxygen Files</h4></div></div></div><p>
The Makefile rules
</p><pre class="screen"><strong class="userinput"><code>make doc-html-doxygen</code></strong></pre><p>
and
</p><pre class="screen"><strong class="userinput"><code>make doc-xml-doxygen</code></strong></pre><p>
and
</p><pre class="screen"><strong class="userinput"><code>make doc-man-doxygen</code></strong></pre><p>
in the libstdc++ build directory generate the HTML docs, the
XML docs, and the man pages.
</p><p>
Careful observers will see that the Makefile rules simply call
a script from the source tree, <code class="filename">run_doxygen</code>, which
does the actual work of running Doxygen and then (most
importantly) massaging the output files. If for some reason
you prefer to not go through the Makefile, you can call this
script directly. (Start by passing <code class="literal">--help</code>.)
</p><p>
If you wish to tweak the Doxygen settings, do so by editing
<code class="filename">doc/doxygen/user.cfg.in</code>. Notes to fellow
library hackers are written in triple-# comments.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="doxygen.markup"></a>Markup</h4></div></div></div><p>
In general, libstdc++ files should be formatted according to
the rules found in the
<a class="link" href="bk01apas03.html" title="Coding Style">Coding Standard</a>. Before
any doxygen-specific formatting tweaks are made, please try to
make sure that the initial formatting is sound.
</p><p>
Adding Doxygen markup to a file (informally called
“<span class="quote">doxygenating</span>”) is very simple. The Doxygen manual can be
found
<a class="ulink" href="http://www.stack.nl/~dimitri/doxygen/download.html#latestman" target="_top">here</a>.
We try to use a very-recent version of Doxygen.
</p><p>
For classes, use
<code class="classname">deque</code>/<code class="classname">vector</code>/<code class="classname">list</code>
and <code class="classname">std::pair</code> as examples. For
functions, see their member functions, and the free functions
in <code class="filename">stl_algobase.h</code>. Member functions of
other container-like types should read similarly to these
member functions.
</p><p>
These points accompany the first list in section 3.1 of the
Doxygen manual:
</p><div class="orderedlist"><ol type="1"><li><p>Use the Javadoc style...</p></li><li><p>
...not the Qt style. The intermediate *'s are preferred.
</p></li><li><p>
Use the triple-slash style only for one-line comments (the
“<span class="quote">brief</span>” mode). Very recent versions of Doxygen permit
full-mode comments in triple-slash blocks, but the
formatting still comes out wonky.
</p></li><li><p>
This is disgusting. Don't do this.
</p></li></ol></div><p>
Use the @-style of commands, not the !-style. Please be
careful about whitespace in your markup comments. Most of the
time it doesn't matter; doxygen absorbs most whitespace, and
both HTML and *roff are agnostic about whitespace. However,
in &lt;pre&gt; blocks and @code/@endcode sections, spacing can
have “<span class="quote">interesting</span>” effects.
</p><p>
Use either kind of grouping, as
appropriate. <code class="filename">doxygroups.cc</code> exists for this
purpose. See <code class="filename">stl_iterator.h</code> for a good example
of the “<span class="quote">other</span>” kind of grouping.
</p><p>
Please use markup tags like @p and @a when referring to things
such as the names of function parameters. Use @e for emphasis
when necessary. Use @c to refer to other standard names.
(Examples of all these abound in the present code.)
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="doc_style.docbook"></a>Docbook</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="docbook.prereq"></a>Prerequisites</h4></div></div></div><p>
Editing the DocBook sources requires an XML editor. Many
exist: some noteable options
include <span class="command"><strong>emacs</strong></span>, <span class="application">Kate</span>,
or <span class="application">Conglomerate</span>.
</p><p>
Some editors support special “<span class="quote">XML Validation</span>”
modes that can validate the file as it is
produced. Recommended is the <span class="command"><strong>nXML Mode</strong></span>
for <span class="command"><strong>emacs</strong></span>.
</p><p>
Besides an editor, additional DocBook files and XML tools are
also required.
</p><p>
Access to the DocBook stylesheets and DTD is required. The
stylesheets are usually packaged by vendor, in something
like <code class="filename">docbook-style-xsl</code>. The installation
directory for this package corresponds to
the <code class="literal">XSL_STYLE_DIR</code>
in <code class="filename">doc/Makefile.am</code> and defaults
to <code class="filename">/usr/share/sgml/docbook/xsl-stylesheets</code>.
</p><p>
For procesessing XML, an XML processor and some style
sheets are necessary. Defaults are <span class="command"><strong>xsltproc</strong></span>
provided by <code class="filename">libxslt</code>.
</p><p>
For validating the XML document, you'll need
something like <span class="command"><strong>xmllint</strong></span> and access to the
DocBook DTD. These are provided
by a vendor package like <code class="filename">lixml2</code>.
</p><p>
For PDF output, something that transforms valid XML to PDF is
required. Possible solutions include <span class="command"><strong>xmlto</strong></span>,
<a class="ulink" href="http://xmlgraphics.apache.org/fop/" target="_top">Apache
FOP</a>, or <span class="command"><strong>prince</strong></span>. Other options are
listed on the DocBook web <a class="ulink" href="http://wiki.docbook.org/topic/DocBookPublishingTools" target="_top">pages</a>. Please
consult the <code class="email">&lt;<a class="email" href="mailto:libstdc++@gcc.gnu.org">libstdc++@gcc.gnu.org</a>&gt;</code> list when
preparing printed manuals for current best practice and suggestions.
</p><p>
Make sure that the XML documentation and markup is valid for
any change. This can be done easily, with the validation rules
in the <code class="filename">Makefile</code>, which is equivalent to doing:
</p><pre class="screen">
<strong class="userinput"><code>
xmllint --noout --valid <code class="filename">xml/index.xml</code>
</code></strong>
</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="docbook.rules"></a>Generating the DocBook Files</h4></div></div></div><p>
The Makefile rules
</p><pre class="screen"><strong class="userinput"><code>make doc-html</code></strong></pre><p>
and
</p><pre class="screen"><strong class="userinput"><code>make doc-pdf</code></strong></pre><p>
and
</p><pre class="screen"><strong class="userinput"><code>make doc-xml-single</code></strong></pre><p>
and
</p><pre class="screen"><strong class="userinput"><code>make doc-xml-validate</code></strong></pre><p>
in the libstdc++ build directory result respectively in the
following: the generation of an HTML version of all the
documentation, a PDF version of the same, a single XML
document, and the results of validating the XML document.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="docbook.examples"></a>File Organization and Basics</h4></div></div></div><div class="literallayout"><p><br />
      <span class="emphasis"><em>Which files are important</em></span><br />
<br />
      All Docbook files are in the directory<br />
      libstdc++-v3/doc/xml<br />
<br />
      Inside this directory, the files of importance:<br />
      spine.xml   - index to documentation set<br />
      manual/spine.xml  - index to manual<br />
      manual/*.xml   - individual chapters and sections of the manual<br />
      faq.xml   - index to FAQ<br />
      api.xml   - index to source level / API <br />
<br />
      All *.txml files are template xml files, ie otherwise empty files with<br />
      the correct structure, suitable for filling in with new information.<br />
<br />
      <span class="emphasis"><em>Cannonical Writing Style</em></span><br />
<br />
      class template<br />
      function template<br />
      member function template<br />
      (via C++ Templates, Vandevoorde)<br />
<br />
      class in namespace std: allocator, not std::allocator<br />
<br />
      header file: iostream, not &lt;iostream&gt;<br />
<br />
<br />
      <span class="emphasis"><em>General structure</em></span><br />
<br />
      &lt;set&gt;<br />
      &lt;book&gt;<br />
      &lt;/book&gt;<br />
<br />
      &lt;book&gt;<br />
      &lt;chapter&gt;<br />
      &lt;/chapter&gt;<br />
      &lt;/book&gt;<br />
<br />
      &lt;book&gt; <br />
      &lt;part&gt;<br />
      &lt;chapter&gt;<br />
      &lt;section&gt;<br />
      &lt;/section&gt;<br />
<br />
      &lt;sect1&gt;<br />
      &lt;/sect1&gt;<br />
<br />
      &lt;sect1&gt;<br />
      &lt;sect2&gt;<br />
      &lt;/sect2&gt;<br />
      &lt;/sect1&gt;<br />
      &lt;/chapter&gt;<br />
<br />
      &lt;chapter&gt;<br />
      &lt;/chapter&gt;<br />
      &lt;/part&gt;  <br />
      &lt;/book&gt;<br />
<br />
      &lt;/set&gt;<br />
    </p></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="docbook.markup"></a>Markup By Example</h4></div></div></div><div class="literallayout"><p><br />
      HTML to XML rough equivalents<br />
<br />
      &lt;p&gt; &lt;para&gt;<br />
<br />
      &lt;pre&gt; &lt;computeroutput&gt;<br />
      &lt;pre&gt; &lt;programlisting&gt;<br />
      &lt;pre&gt; &lt;literallayout&gt;<br />
<br />
      &lt;ul&gt; &lt;itemizedlist&gt;<br />
      &lt;ol&gt; &lt;orderedlist&gt;<br />
      &lt;il&gt; &lt;listitem&gt;<br />
<br />
      &lt;dl&gt; &lt;variablelist&gt;<br />
<br />
      &lt;varlistentry&gt;<br />
      &lt;dt&gt;    &lt;term&gt;<br />
      &lt;/dt&gt;   &lt;/term&gt;<br />
      &lt;dd&gt;     &lt;listitem&gt;<br />
      &lt;/dt&gt;   &lt;/listitem&gt;<br />
      &lt;/varlistentry&gt;<br />
<br />
      &lt;a href &lt;ulink url<br />
      &lt;code&gt; &lt;literal&gt;<br />
      &lt;code&gt; &lt;programlisting&gt;<br />
<br />
      &lt;strong&gt; &lt;emphasis&gt;<br />
      &lt;em&gt; &lt;emphasis&gt;<br />
      " &lt;quote&gt;<br />
<br />
      ctype.h &lt;filename class="headerfile"&gt;&lt;/filename&gt;<br />
<br />
      <br />
      build_dir    &lt;filename class="directory"&gt;path_to_build_dir&lt;/filename&gt;<br />
<br />
      Finer gradations of &lt;code&gt;<br />
<br />
      &lt;classname&gt; &lt;classname&gt;string&lt;/classname&gt;<br />
      &lt;classname&gt;vector&lt;&gt;&lt;/classname&gt; <br />
      &lt;function&gt;fs.clear()&lt;/function&gt;<br />
<br />
      &lt;structname&gt;<br />
<br />
      &lt;function&gt; &lt;function&gt;clear()&lt;/function&gt;<br />
<br />
      &lt;type&gt; &lt;type&gt;long long&lt;/type&gt;<br />
<br />
      &lt;varname&gt; &lt;varname&gt;fs&lt;/varname&gt;<br />
<br />
      &lt;literal&gt; &lt;literal&gt;-Weffc++&lt;/literal&gt; <br />
      &lt;literal&gt;rel_ops&lt;/literal&gt;<br />
<br />
      &lt;constant&gt; &lt;constant&gt;_GNU_SOURCE&lt;/constant&gt;<br />
      &lt;constant&gt;3.0&lt;/constant&gt;<br />
<br />
      &lt;filename&gt;<br />
<br />
      &lt;command&gt; &lt;command&gt;g++&lt;/command&gt;<br />
<br />
      &lt;errortext&gt; &lt;errortext&gt;foo Concept &lt;/errortext&gt;<br />
</p></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01apas03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_contributing.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01apas05.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Coding Style </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Design Notes</td></tr></table></div></body></html>

857
libstdc++-v3/doc/html/manual/bk01apas05.html Normal file
View File

@ -0,0 +1,857 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Design Notes</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_contributing.html" title="Appendix A. Contributing" /><link rel="prev" href="bk01apas04.html" title="Documentation Style" /><link rel="next" href="appendix_porting.html" title="Appendix B. Porting and Maintenance" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Design Notes</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01apas04.html">Prev</a> </td><th width="60%" align="center">Appendix A. Contributing</th><td width="20%" align="right"> <a accesskey="n" href="appendix_porting.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contrib.design_notes"></a>Design Notes</h2></div></div></div><p>
</p><div class="literallayout"><p><br />
<br />
    The Library<br />
    -----------<br />
<br />
    This paper is covers two major areas:<br />
<br />
    - Features and policies not mentioned in the standard that<br />
    the quality of the library implementation depends on, including<br />
    extensions and "implementation-defined" features;<br />
<br />
    - Plans for required but unimplemented library features and<br />
    optimizations to them.<br />
<br />
    Overhead<br />
    --------<br />
<br />
    The standard defines a large library, much larger than the standard<br />
    C library. A naive implementation would suffer substantial overhead<br />
    in compile time, executable size, and speed, rendering it unusable<br />
    in many (particularly embedded) applications. The alternative demands<br />
    care in construction, and some compiler support, but there is no<br />
    need for library subsets.<br />
<br />
    What are the sources of this overhead?  There are four main causes:<br />
<br />
    - The library is specified almost entirely as templates, which<br />
    with current compilers must be included in-line, resulting in<br />
    very slow builds as tens or hundreds of thousands of lines<br />
    of function definitions are read for each user source file.<br />
    Indeed, the entire SGI STL, as well as the dos Reis valarray,<br />
    are provided purely as header files, largely for simplicity in<br />
    porting. Iostream/locale is (or will be) as large again.<br />
<br />
    - The library is very flexible, specifying a multitude of hooks<br />
    where users can insert their own code in place of defaults.<br />
    When these hooks are not used, any time and code expended to<br />
    support that flexibility is wasted.<br />
<br />
    - Templates are often described as causing to "code bloat". In<br />
    practice, this refers (when it refers to anything real) to several<br />
    independent processes. First, when a class template is manually<br />
    instantiated in its entirely, current compilers place the definitions<br />
    for all members in a single object file, so that a program linking<br />
    to one member gets definitions of all. Second, template functions<br />
    which do not actually depend on the template argument are, under<br />
    current compilers, generated anew for each instantiation, rather<br />
    than being shared with other instantiations. Third, some of the<br />
    flexibility mentioned above comes from virtual functions (both in<br />
    regular classes and template classes) which current linkers add<br />
    to the executable file even when they manifestly cannot be called.<br />
<br />
    - The library is specified to use a language feature, exceptions,<br />
    which in the current gcc compiler ABI imposes a run time and<br />
    code space cost to handle the possibility of exceptions even when<br />
    they are not used. Under the new ABI (accessed with -fnew-abi),<br />
    there is a space overhead and a small reduction in code efficiency<br />
    resulting from lost optimization opportunities associated with<br />
    non-local branches associated with exceptions.<br />
<br />
    What can be done to eliminate this overhead?  A variety of coding<br />
    techniques, and compiler, linker and library improvements and<br />
    extensions may be used, as covered below. Most are not difficult,<br />
    and some are already implemented in varying degrees.<br />
<br />
    Overhead: Compilation Time<br />
    --------------------------<br />
<br />
    Providing "ready-instantiated" template code in object code archives<br />
    allows us to avoid generating and optimizing template instantiations<br />
    in each compilation unit which uses them. However, the number of such<br />
    instantiations that are useful to provide is limited, and anyway this<br />
    is not enough, by itself, to minimize compilation time. In particular,<br />
    it does not reduce time spent parsing conforming headers.<br />
<br />
    Quicker header parsing will depend on library extensions and compiler<br />
    improvements.  One approach is some variation on the techniques<br />
    previously marketed as "pre-compiled headers", now standardized as<br />
    support for the "export" keyword. "Exported" template definitions<br />
    can be placed (once) in a "repository" -- really just a library, but<br />
    of template definitions rather than object code -- to be drawn upon<br />
    at link time when an instantiation is needed, rather than placed in<br />
    header files to be parsed along with every compilation unit.<br />
<br />
    Until "export" is implemented we can put some of the lengthy template<br />
    definitions in #if guards or alternative headers so that users can skip<br />
    over the full definitions when they need only the ready-instantiated<br />
    specializations.<br />
<br />
    To be precise, this means that certain headers which define<br />
    templates which users normally use only for certain arguments<br />
    can be instrumented to avoid exposing the template definitions<br />
    to the compiler unless a macro is defined. For example, in<br />
    &lt;string&gt;, we might have:<br />
<br />
    template &lt;class _CharT, ... &gt; class basic_string {<br />
    ... // member declarations<br />
    };<br />
    ... // operator declarations<br />
<br />
    #ifdef _STRICT_ISO_<br />
    # if _G_NO_TEMPLATE_EXPORT<br />
    #   include &lt;bits/std_locale.h&gt;  // headers needed by definitions<br />
    #   ...<br />
    #   include &lt;bits/string.tcc&gt;  // member and global template definitions.<br />
    # endif<br />
    #endif<br />
<br />
    Users who compile without specifying a strict-ISO-conforming flag<br />
    would not see many of the template definitions they now see, and rely<br />
    instead on ready-instantiated specializations in the library. This<br />
    technique would be useful for the following substantial components:<br />
    string, locale/iostreams, valarray. It would *not* be useful or<br />
    usable with the following: containers, algorithms, iterators,<br />
    allocator. Since these constitute a large (though decreasing)<br />
    fraction of the library, the benefit the technique offers is<br />
    limited.<br />
<br />
    The language specifies the semantics of the "export" keyword, but<br />
    the gcc compiler does not yet support it. When it does, problems<br />
    with large template inclusions can largely disappear, given some<br />
    minor library reorganization, along with the need for the apparatus<br />
    described above.<br />
<br />
    Overhead: Flexibility Cost<br />
    --------------------------<br />
<br />
    The library offers many places where users can specify operations<br />
    to be performed by the library in place of defaults. Sometimes<br />
    this seems to require that the library use a more-roundabout, and<br />
    possibly slower, way to accomplish the default requirements than<br />
    would be used otherwise.<br />
<br />
    The primary protection against this overhead is thorough compiler<br />
    optimization, to crush out layers of inline function interfaces.<br />
    Kuck &amp; Associates has demonstrated the practicality of this kind<br />
    of optimization.<br />
<br />
    The second line of defense against this overhead is explicit<br />
    specialization. By defining helper function templates, and writing<br />
    specialized code for the default case, overhead can be eliminated<br />
    for that case without sacrificing flexibility. This takes full<br />
    advantage of any ability of the optimizer to crush out degenerate<br />
    code.<br />
<br />
    The library specifies many virtual functions which current linkers<br />
    load even when they cannot be called. Some minor improvements to the<br />
    compiler and to ld would eliminate any such overhead by simply<br />
    omitting virtual functions that the complete program does not call.<br />
    A prototype of this work has already been done. For targets where<br />
    GNU ld is not used, a "pre-linker" could do the same job.<br />
<br />
    The main areas in the standard interface where user flexibility<br />
    can result in overhead are:<br />
<br />
    - Allocators:  Containers are specified to use user-definable<br />
    allocator types and objects, making tuning for the container<br />
    characteristics tricky.<br />
<br />
    - Locales: the standard specifies locale objects used to implement<br />
    iostream operations, involving many virtual functions which use<br />
    streambuf iterators.<br />
<br />
    - Algorithms and containers: these may be instantiated on any type,<br />
    frequently duplicating code for identical operations.<br />
<br />
    - Iostreams and strings: users are permitted to use these on their<br />
    own types, and specify the operations the stream must use on these<br />
    types.<br />
<br />
    Note that these sources of overhead are _avoidable_. The techniques<br />
    to avoid them are covered below.<br />
<br />
    Code Bloat<br />
    ----------<br />
<br />
    In the SGI STL, and in some other headers, many of the templates<br />
    are defined "inline" -- either explicitly or by their placement<br />
    in class definitions -- which should not be inline. This is a<br />
    source of code bloat. Matt had remarked that he was relying on<br />
    the compiler to recognize what was too big to benefit from inlining,<br />
    and generate it out-of-line automatically. However, this also can<br />
    result in code bloat except where the linker can eliminate the extra<br />
    copies.<br />
<br />
    Fixing these cases will require an audit of all inline functions<br />
    defined in the library to determine which merit inlining, and moving<br />
    the rest out of line. This is an issue mainly in chapters 23, 25, and<br />
    27. Of course it can be done incrementally, and we should generally<br />
    accept patches that move large functions out of line and into ".tcc"<br />
    files, which can later be pulled into a repository. Compiler/linker<br />
    improvements to recognize very large inline functions and move them<br />
    out-of-line, but shared among compilation units, could make this<br />
    work unnecessary.<br />
<br />
    Pre-instantiating template specializations currently produces large<br />
    amounts of dead code which bloats statically linked programs. The<br />
    current state of the static library, libstdc++.a, is intolerable on<br />
    this account, and will fuel further confused speculation about a need<br />
    for a library "subset". A compiler improvement that treats each<br />
    instantiated function as a separate object file, for linking purposes,<br />
    would be one solution to this problem. An alternative would be to<br />
    split up the manual instantiation files into dozens upon dozens of<br />
    little files, each compiled separately, but an abortive attempt at<br />
    this was done for &lt;string&gt; and, though it is far from complete, it<br />
    is already a nuisance. A better interim solution (just until we have<br />
    "export") is badly needed.<br />
<br />
    When building a shared library, the current compiler/linker cannot<br />
    automatically generate the instantiatiations needed. This creates a<br />
    miserable situation; it means any time something is changed in the<br />
    library, before a shared library can be built someone must manually<br />
    copy the declarations of all templates that are needed by other parts<br />
    of the library to an "instantiation" file, and add it to the build<br />
    system to be compiled and linked to the library. This process is<br />
    readily automated, and should be automated as soon as possible.<br />
    Users building their own shared libraries experience identical<br />
    frustrations.<br />
<br />
    Sharing common aspects of template definitions among instantiations<br />
    can radically reduce code bloat. The compiler could help a great<br />
    deal here by recognizing when a function depends on nothing about<br />
    a template parameter, or only on its size, and giving the resulting<br />
    function a link-name "equate" that allows it to be shared with other<br />
    instantiations. Implementation code could take advantage of the<br />
    capability by factoring out code that does not depend on the template<br />
    argument into separate functions to be merged by the compiler.<br />
<br />
    Until such a compiler optimization is implemented, much can be done<br />
    manually (if tediously) in this direction. One such optimization is<br />
    to derive class templates from non-template classes, and move as much<br />
    implementation as possible into the base class. Another is to partial-<br />
    specialize certain common instantiations, such as vector&lt;T*&gt;, to share<br />
    code for instantiations on all types T. While these techniques work,<br />
    they are far from the complete solution that a compiler improvement<br />
    would afford.<br />
<br />
    Overhead: Expensive Language Features<br />
    -------------------------------------<br />
<br />
    The main "expensive" language feature used in the standard library<br />
    is exception support, which requires compiling in cleanup code with<br />
    static table data to locate it, and linking in library code to use<br />
    the table. For small embedded programs the amount of such library<br />
    code and table data is assumed by some to be excessive. Under the<br />
    "new" ABI this perception is generally exaggerated, although in some<br />
    cases it may actually be excessive.<br />
<br />
    To implement a library which does not use exceptions directly is<br />
    not difficult given minor compiler support (to "turn off" exceptions<br />
    and ignore exception constructs), and results in no great library<br />
    maintenance difficulties. To be precise, given "-fno-exceptions",<br />
    the compiler should treat "try" blocks as ordinary blocks, and<br />
    "catch" blocks as dead code to ignore or eliminate. Compiler<br />
    support is not strictly necessary, except in the case of "function<br />
    try blocks"; otherwise the following macros almost suffice:<br />
<br />
    #define throw(X)<br />
    #define try      if (true)<br />
    #define catch(X) else if (false)<br />
<br />
    However, there may be a need to use function try blocks in the<br />
    library implementation, and use of macros in this way can make<br />
    correct diagnostics impossible. Furthermore, use of this scheme<br />
    would require the library to call a function to re-throw exceptions<br />
    from a try block. Implementing the above semantics in the compiler<br />
    is preferable.<br />
<br />
    Given the support above (however implemented) it only remains to<br />
    replace code that "throws" with a call to a well-documented "handler"<br />
    function in a separate compilation unit which may be replaced by<br />
    the user. The main source of exceptions that would be difficult<br />
    for users to avoid is memory allocation failures, but users can<br />
    define their own memory allocation primitives that never throw.<br />
    Otherwise, the complete list of such handlers, and which library<br />
    functions may call them, would be needed for users to be able to<br />
    implement the necessary substitutes. (Fortunately, they have the<br />
    source code.)<br />
<br />
    Opportunities<br />
    -------------<br />
<br />
    The template capabilities of C++ offer enormous opportunities for<br />
    optimizing common library operations, well beyond what would be<br />
    considered "eliminating overhead". In particular, many operations<br />
    done in Glibc with macros that depend on proprietary language<br />
    extensions can be implemented in pristine Standard C++. For example,<br />
    the chapter 25 algorithms, and even C library functions such as strchr,<br />
    can be specialized for the case of static arrays of known (small) size.<br />
<br />
    Detailed optimization opportunities are identified below where<br />
    the component where they would appear is discussed. Of course new<br />
    opportunities will be identified during implementation.<br />
<br />
    Unimplemented Required Library Features<br />
    ---------------------------------------<br />
<br />
    The standard specifies hundreds of components, grouped broadly by<br />
    chapter. These are listed in excruciating detail in the CHECKLIST<br />
    file.<br />
<br />
    17 general<br />
    18 support<br />
    19 diagnostics<br />
    20 utilities<br />
    21 string<br />
    22 locale<br />
    23 containers<br />
    24 iterators<br />
    25 algorithms<br />
    26 numerics<br />
    27 iostreams<br />
    Annex D  backward compatibility<br />
<br />
    Anyone participating in implementation of the library should obtain<br />
    a copy of the standard, ISO 14882.  People in the U.S. can obtain an<br />
    electronic copy for US$18 from ANSI's web site. Those from other<br />
    countries should visit http://www.iso.ch/ to find out the location<br />
    of their country's representation in ISO, in order to know who can<br />
    sell them a copy.<br />
<br />
    The emphasis in the following sections is on unimplemented features<br />
    and optimization opportunities.<br />
<br />
    Chapter 17  General<br />
    -------------------<br />
<br />
    Chapter 17 concerns overall library requirements.<br />
<br />
    The standard doesn't mention threads. A multi-thread (MT) extension<br />
    primarily affects operators new and delete (18), allocator (20),<br />
    string (21), locale (22), and iostreams (27). The common underlying<br />
    support needed for this is discussed under chapter 20.<br />
<br />
    The standard requirements on names from the C headers create a<br />
    lot of work, mostly done. Names in the C headers must be visible<br />
    in the std:: and sometimes the global namespace; the names in the<br />
    two scopes must refer to the same object. More stringent is that<br />
    Koenig lookup implies that any types specified as defined in std::<br />
    really are defined in std::. Names optionally implemented as<br />
    macros in C cannot be macros in C++. (An overview may be read at<br />
    &lt;http://www.cantrip.org/cheaders.html&gt;). The scripts "inclosure"<br />
    and "mkcshadow", and the directories shadow/ and cshadow/, are the<br />
    beginning of an effort to conform in this area.<br />
<br />
    A correct conforming definition of C header names based on underlying<br />
    C library headers, and practical linking of conforming namespaced<br />
    customer code with third-party C libraries depends ultimately on<br />
    an ABI change, allowing namespaced C type names to be mangled into<br />
    type names as if they were global, somewhat as C function names in a<br />
    namespace, or C++ global variable names, are left unmangled. Perhaps<br />
    another "extern" mode, such as 'extern "C-global"' would be an<br />
    appropriate place for such type definitions. Such a type would<br />
    affect mangling as follows:<br />
<br />
    namespace A {<br />
    struct X {};<br />
    extern "C-global" {  // or maybe just 'extern "C"'<br />
    struct Y {};<br />
    };<br />
    }<br />
    void f(A::X*);  // mangles to f__FPQ21A1X<br />
    void f(A::Y*);  // mangles to f__FP1Y<br />
<br />
    (It may be that this is really the appropriate semantics for regular<br />
    'extern "C"', and 'extern "C-global"', as an extension, would not be<br />
    necessary.) This would allow functions declared in non-standard C headers<br />
    (and thus fixable by neither us nor users) to link properly with functions<br />
    declared using C types defined in properly-namespaced headers. The<br />
    problem this solves is that C headers (which C++ programmers do persist<br />
    in using) frequently forward-declare C struct tags without including<br />
    the header where the type is defined, as in<br />
<br />
    struct tm;<br />
    void munge(tm*);<br />
<br />
    Without some compiler accommodation, munge cannot be called by correct<br />
    C++ code using a pointer to a correctly-scoped tm* value.<br />
<br />
    The current C headers use the preprocessor extension "#include_next",<br />
    which the compiler complains about when run "-pedantic".<br />
    (Incidentally, it appears that "-fpedantic" is currently ignored,<br />
    probably a bug.)  The solution in the C compiler is to use<br />
    "-isystem" rather than "-I", but unfortunately in g++ this seems<br />
    also to wrap the whole header in an 'extern "C"' block, so it's<br />
    unusable for C++ headers. The correct solution appears to be to<br />
    allow the various special include-directory options, if not given<br />
    an argument, to affect subsequent include-directory options additively,<br />
    so that if one said<br />
<br />
    -pedantic -iprefix $(prefix) \<br />
    -idirafter -ino-pedantic -ino-extern-c -iwithprefix -I g++-v3 \<br />
    -iwithprefix -I g++-v3/ext<br />
<br />
    the compiler would search $(prefix)/g++-v3 and not report<br />
    pedantic warnings for files found there, but treat files in<br />
    $(prefix)/g++-v3/ext pedantically. (The undocumented semantics<br />
    of "-isystem" in g++ stink. Can they be rescinded?  If not it<br />
    must be replaced with something more rationally behaved.)<br />
<br />
    All the C headers need the treatment above; in the standard these<br />
    headers are mentioned in various chapters. Below, I have only<br />
    mentioned those that present interesting implementation issues.<br />
<br />
    The components identified as "mostly complete", below, have not been<br />
    audited for conformance. In many cases where the library passes<br />
    conformance tests we have non-conforming extensions that must be<br />
    wrapped in #if guards for "pedantic" use, and in some cases renamed<br />
    in a conforming way for continued use in the implementation regardless<br />
    of conformance flags.<br />
<br />
    The STL portion of the library still depends on a header<br />
    stl/bits/stl_config.h full of #ifdef clauses. This apparatus<br />
    should be replaced with autoconf/automake machinery.<br />
<br />
    The SGI STL defines a type_traits&lt;&gt; template, specialized for<br />
    many types in their code including the built-in numeric and<br />
    pointer types and some library types, to direct optimizations of<br />
    standard functions. The SGI compiler has been extended to generate<br />
    specializations of this template automatically for user types,<br />
    so that use of STL templates on user types can take advantage of<br />
    these optimizations. Specializations for other, non-STL, types<br />
    would make more optimizations possible, but extending the gcc<br />
    compiler in the same way would be much better. Probably the next<br />
    round of standardization will ratify this, but probably with<br />
    changes, so it probably should be renamed to place it in the<br />
    implementation namespace.<br />
<br />
    The SGI STL also defines a large number of extensions visible in<br />
    standard headers. (Other extensions that appear in separate headers<br />
    have been sequestered in subdirectories ext/ and backward/.)  All<br />
    these extensions should be moved to other headers where possible,<br />
    and in any case wrapped in a namespace (not std!), and (where kept<br />
    in a standard header) girded about with macro guards. Some cannot be<br />
    moved out of standard headers because they are used to implement<br />
    standard features.  The canonical method for accommodating these<br />
    is to use a protected name, aliased in macro guards to a user-space<br />
    name. Unfortunately C++ offers no satisfactory template typedef<br />
    mechanism, so very ad-hoc and unsatisfactory aliasing must be used<br />
    instead.<br />
<br />
    Implementation of a template typedef mechanism should have the highest<br />
    priority among possible extensions, on the same level as implementation<br />
    of the template "export" feature.<br />
<br />
    Chapter 18  Language support<br />
    ----------------------------<br />
<br />
    Headers: &lt;limits&gt; &lt;new&gt; &lt;typeinfo&gt; &lt;exception&gt;<br />
    C headers: &lt;cstddef&gt; &lt;climits&gt; &lt;cfloat&gt;  &lt;cstdarg&gt; &lt;csetjmp&gt;<br />
    &lt;ctime&gt;   &lt;csignal&gt; &lt;cstdlib&gt; (also 21, 25, 26)<br />
<br />
    This defines the built-in exceptions, rtti, numeric_limits&lt;&gt;,<br />
    operator new and delete. Much of this is provided by the<br />
    compiler in its static runtime library.<br />
<br />
    Work to do includes defining numeric_limits&lt;&gt; specializations in<br />
    separate files for all target architectures. Values for integer types<br />
    except for bool and wchar_t are readily obtained from the C header<br />
    &lt;limits.h&gt;, but values for the remaining numeric types (bool, wchar_t,<br />
    float, double, long double) must be entered manually. This is<br />
    largely dog work except for those members whose values are not<br />
    easily deduced from available documentation. Also, this involves<br />
    some work in target configuration to identify the correct choice of<br />
    file to build against and to install.<br />
<br />
    The definitions of the various operators new and delete must be<br />
    made thread-safe, which depends on a portable exclusion mechanism,<br />
    discussed under chapter 20.  Of course there is always plenty of<br />
    room for improvements to the speed of operators new and delete.<br />
<br />
    &lt;cstdarg&gt;, in Glibc, defines some macros that gcc does not allow to<br />
    be wrapped into an inline function. Probably this header will demand<br />
    attention whenever a new target is chosen. The functions atexit(),<br />
    exit(), and abort() in cstdlib have different semantics in C++, so<br />
    must be re-implemented for C++.<br />
<br />
    Chapter 19  Diagnostics<br />
    -----------------------<br />
<br />
    Headers: &lt;stdexcept&gt;<br />
    C headers: &lt;cassert&gt; &lt;cerrno&gt;<br />
<br />
    This defines the standard exception objects, which are "mostly complete".<br />
    Cygnus has a version, and now SGI provides a slightly different one.<br />
    It makes little difference which we use.<br />
<br />
    The C global name "errno", which C allows to be a variable or a macro,<br />
    is required in C++ to be a macro. For MT it must typically result in<br />
    a function call.<br />
<br />
    Chapter 20  Utilities<br />
    ---------------------<br />
    Headers: &lt;utility&gt; &lt;functional&gt; &lt;memory&gt;<br />
    C header: &lt;ctime&gt; (also in 18)<br />
<br />
    SGI STL provides "mostly complete" versions of all the components<br />
    defined in this chapter. However, the auto_ptr&lt;&gt; implementation<br />
    is known to be wrong. Furthermore, the standard definition of it<br />
    is known to be unimplementable as written. A minor change to the<br />
    standard would fix it, and auto_ptr&lt;&gt; should be adjusted to match.<br />
<br />
    Multi-threading affects the allocator implementation, and there must<br />
    be configuration/installation choices for different users' MT<br />
    requirements. Anyway, users will want to tune allocator options<br />
    to support different target conditions, MT or no.<br />
<br />
    The primitives used for MT implementation should be exposed, as an<br />
    extension, for users' own work. We need cross-CPU "mutex" support,<br />
    multi-processor shared-memory atomic integer operations, and single-<br />
    processor uninterruptible integer operations, and all three configurable<br />
    to be stubbed out for non-MT use, or to use an appropriately-loaded<br />
    dynamic library for the actual runtime environment, or statically<br />
    compiled in for cases where the target architecture is known.<br />
<br />
    Chapter 21  String<br />
    ------------------<br />
    Headers: &lt;string&gt;<br />
    C headers: &lt;cctype&gt; &lt;cwctype&gt; &lt;cstring&gt; &lt;cwchar&gt; (also in 27)<br />
    &lt;cstdlib&gt; (also in 18, 25, 26)<br />
<br />
    We have "mostly-complete" char_traits&lt;&gt; implementations. Many of the<br />
    char_traits&lt;char&gt; operations might be optimized further using existing<br />
    proprietary language extensions.<br />
<br />
    We have a "mostly-complete" basic_string&lt;&gt; implementation. The work<br />
    to manually instantiate char and wchar_t specializations in object<br />
    files to improve link-time behavior is extremely unsatisfactory,<br />
    literally tripling library-build time with no commensurate improvement<br />
    in static program link sizes. It must be redone. (Similar work is<br />
    needed for some components in chapters 22 and 27.)<br />
<br />
    Other work needed for strings is MT-safety, as discussed under the<br />
    chapter 20 heading.<br />
<br />
    The standard C type mbstate_t from &lt;cwchar&gt; and used in char_traits&lt;&gt;<br />
    must be different in C++ than in C, because in C++ the default constructor<br />
    value mbstate_t() must be the "base" or "ground" sequence state.<br />
    (According to the likely resolution of a recently raised Core issue,<br />
    this may become unnecessary. However, there are other reasons to<br />
    use a state type not as limited as whatever the C library provides.)<br />
    If we might want to provide conversions from (e.g.) internally-<br />
    represented EUC-wide to externally-represented Unicode, or vice-<br />
    versa, the mbstate_t we choose will need to be more accommodating<br />
    than what might be provided by an underlying C library.<br />
<br />
    There remain some basic_string template-member functions which do<br />
    not overload properly with their non-template brethren. The infamous<br />
    hack akin to what was done in vector&lt;&gt; is needed, to conform to<br />
    23.1.1 para 10. The CHECKLIST items for basic_string marked 'X',<br />
    or incomplete, are so marked for this reason.<br />
<br />
    Replacing the string iterators, which currently are simple character<br />
    pointers, with class objects would greatly increase the safety of the<br />
    client interface, and also permit a "debug" mode in which range,<br />
    ownership, and validity are rigorously checked. The current use of<br />
    raw pointers as string iterators is evil. vector&lt;&gt; iterators need the<br />
    same treatment. Note that the current implementation freely mixes<br />
    pointers and iterators, and that must be fixed before safer iterators<br />
    can be introduced.<br />
<br />
    Some of the functions in &lt;cstring&gt; are different from the C version.<br />
    generally overloaded on const and non-const argument pointers. For<br />
    example, in &lt;cstring&gt; strchr is overloaded. The functions isupper<br />
    etc. in &lt;cctype&gt; typically implemented as macros in C are functions<br />
    in C++, because they are overloaded with others of the same name<br />
    defined in &lt;locale&gt;.<br />
<br />
    Many of the functions required in &lt;cwctype&gt; and &lt;cwchar&gt; cannot be<br />
    implemented using underlying C facilities on intended targets because<br />
    such facilities only partly exist.<br />
<br />
    Chapter 22  Locale<br />
    ------------------<br />
    Headers: &lt;locale&gt;<br />
    C headers: &lt;clocale&gt;<br />
<br />
    We have a "mostly complete" class locale, with the exception of<br />
    code for constructing, and handling the names of, named locales.<br />
    The ways that locales are named (particularly when categories<br />
    (e.g. LC_TIME, LC_COLLATE) are different) varies among all target<br />
    environments. This code must be written in various versions and<br />
    chosen by configuration parameters.<br />
<br />
    Members of many of the facets defined in &lt;locale&gt; are stubs. Generally,<br />
    there are two sets of facets: the base class facets (which are supposed<br />
    to implement the "C" locale) and the "byname" facets, which are supposed<br />
    to read files to determine their behavior. The base ctype&lt;&gt;, collate&lt;&gt;,<br />
    and numpunct&lt;&gt; facets are "mostly complete", except that the table of<br />
    bitmask values used for "is" operations, and corresponding mask values,<br />
    are still defined in libio and just included/linked. (We will need to<br />
    implement these tables independently, soon, but should take advantage<br />
    of libio where possible.)  The num_put&lt;&gt;::put members for integer types<br />
    are "mostly complete".<br />
<br />
    A complete list of what has and has not been implemented may be<br />
    found in CHECKLIST. However, note that the current definition of<br />
    codecvt&lt;wchar_t,char,mbstate_t&gt; is wrong. It should simply write<br />
    out the raw bytes representing the wide characters, rather than<br />
    trying to convert each to a corresponding single "char" value.<br />
<br />
    Some of the facets are more important than others. Specifically,<br />
    the members of ctype&lt;&gt;, numpunct&lt;&gt;, num_put&lt;&gt;, and num_get&lt;&gt; facets<br />
    are used by other library facilities defined in &lt;string&gt;, &lt;istream&gt;,<br />
    and &lt;ostream&gt;, and the codecvt&lt;&gt; facet is used by basic_filebuf&lt;&gt;<br />
    in &lt;fstream&gt;, so a conforming iostream implementation depends on<br />
    these.<br />
<br />
    The "long long" type eventually must be supported, but code mentioning<br />
    it should be wrapped in #if guards to allow pedantic-mode compiling.<br />
<br />
    Performance of num_put&lt;&gt; and num_get&lt;&gt; depend critically on<br />
    caching computed values in ios_base objects, and on extensions<br />
    to the interface with streambufs.<br />
<br />
    Specifically: retrieving a copy of the locale object, extracting<br />
    the needed facets, and gathering data from them, for each call to<br />
    (e.g.) operator&lt;&lt; would be prohibitively slow.  To cache format<br />
    data for use by num_put&lt;&gt; and num_get&lt;&gt; we have a _Format_cache&lt;&gt;<br />
    object stored in the ios_base::pword() array. This is constructed<br />
    and initialized lazily, and is organized purely for utility. It<br />
    is discarded when a new locale with different facets is imbued.<br />
<br />
    Using only the public interfaces of the iterator arguments to the<br />
    facet functions would limit performance by forbidding "vector-style"<br />
    character operations. The streambuf iterator optimizations are<br />
    described under chapter 24, but facets can also bypass the streambuf<br />
    iterators via explicit specializations and operate directly on the<br />
    streambufs, and use extended interfaces to get direct access to the<br />
    streambuf internal buffer arrays. These extensions are mentioned<br />
    under chapter 27. These optimizations are particularly important<br />
    for input parsing.<br />
<br />
    Unused virtual members of locale facets can be omitted, as mentioned<br />
    above, by a smart linker.<br />
<br />
    Chapter 23  Containers<br />
    ----------------------<br />
    Headers: &lt;deque&gt; &lt;list&gt; &lt;queue&gt; &lt;stack&gt; &lt;vector&gt; &lt;map&gt; &lt;set&gt; &lt;bitset&gt;<br />
<br />
    All the components in chapter 23 are implemented in the SGI STL.<br />
    They are "mostly complete"; they include a large number of<br />
    nonconforming extensions which must be wrapped. Some of these<br />
    are used internally and must be renamed or duplicated.<br />
<br />
    The SGI components are optimized for large-memory environments. For<br />
    embedded targets, different criteria might be more appropriate. Users<br />
    will want to be able to tune this behavior. We should provide<br />
    ways for users to compile the library with different memory usage<br />
    characteristics.<br />
<br />
    A lot more work is needed on factoring out common code from different<br />
    specializations to reduce code size here and in chapter 25. The<br />
    easiest fix for this would be a compiler/ABI improvement that allows<br />
    the compiler to recognize when a specialization depends only on the<br />
    size (or other gross quality) of a template argument, and allow the<br />
    linker to share the code with similar specializations. In its<br />
    absence, many of the algorithms and containers can be partial-<br />
    specialized, at least for the case of pointers, but this only solves<br />
    a small part of the problem. Use of a type_traits-style template<br />
    allows a few more optimization opportunities, more if the compiler<br />
    can generate the specializations automatically.<br />
<br />
    As an optimization, containers can specialize on the default allocator<br />
    and bypass it, or take advantage of details of its implementation<br />
    after it has been improved upon.<br />
<br />
    Replacing the vector iterators, which currently are simple element<br />
    pointers, with class objects would greatly increase the safety of the<br />
    client interface, and also permit a "debug" mode in which range,<br />
    ownership, and validity are rigorously checked. The current use of<br />
    pointers for iterators is evil.<br />
<br />
    As mentioned for chapter 24, the deque iterator is a good example of<br />
    an opportunity to implement a "staged" iterator that would benefit<br />
    from specializations of some algorithms.<br />
<br />
    Chapter 24  Iterators<br />
    ---------------------<br />
    Headers: &lt;iterator&gt;<br />
<br />
    Standard iterators are "mostly complete", with the exception of<br />
    the stream iterators, which are not yet templatized on the<br />
    stream type. Also, the base class template iterator&lt;&gt; appears<br />
    to be wrong, so everything derived from it must also be wrong,<br />
    currently.<br />
<br />
    The streambuf iterators (currently located in stl/bits/std_iterator.h,<br />
    but should be under bits/) can be rewritten to take advantage of<br />
    friendship with the streambuf implementation.<br />
<br />
    Matt Austern has identified opportunities where certain iterator<br />
    types, particularly including streambuf iterators and deque<br />
    iterators, have a "two-stage" quality, such that an intermediate<br />
    limit can be checked much more quickly than the true limit on<br />
    range operations. If identified with a member of iterator_traits,<br />
    algorithms may be specialized for this case. Of course the<br />
    iterators that have this quality can be identified by specializing<br />
    a traits class.<br />
<br />
    Many of the algorithms must be specialized for the streambuf<br />
    iterators, to take advantage of block-mode operations, in order<br />
    to allow iostream/locale operations' performance not to suffer.<br />
    It may be that they could be treated as staged iterators and<br />
    take advantage of those optimizations.<br />
<br />
    Chapter 25  Algorithms<br />
    ----------------------<br />
    Headers: &lt;algorithm&gt;<br />
    C headers: &lt;cstdlib&gt; (also in 18, 21, 26))<br />
<br />
    The algorithms are "mostly complete". As mentioned above, they<br />
    are optimized for speed at the expense of code and data size.<br />
<br />
    Specializations of many of the algorithms for non-STL types would<br />
    give performance improvements, but we must use great care not to<br />
    interfere with fragile template overloading semantics for the<br />
    standard interfaces. Conventionally the standard function template<br />
    interface is an inline which delegates to a non-standard function<br />
    which is then overloaded (this is already done in many places in<br />
    the library). Particularly appealing opportunities for the sake of<br />
    iostream performance are for copy and find applied to streambuf<br />
    iterators or (as noted elsewhere) for staged iterators, of which<br />
    the streambuf iterators are a good example.<br />
<br />
    The bsearch and qsort functions cannot be overloaded properly as<br />
    required by the standard because gcc does not yet allow overloading<br />
    on the extern-"C"-ness of a function pointer.<br />
<br />
    Chapter 26  Numerics<br />
    --------------------<br />
    Headers: &lt;complex&gt; &lt;valarray&gt; &lt;numeric&gt;<br />
    C headers: &lt;cmath&gt;, &lt;cstdlib&gt; (also 18, 21, 25)<br />
<br />
    Numeric components: Gabriel dos Reis's valarray, Drepper's complex,<br />
    and the few algorithms from the STL are "mostly done".  Of course<br />
    optimization opportunities abound for the numerically literate. It<br />
    is not clear whether the valarray implementation really conforms<br />
    fully, in the assumptions it makes about aliasing (and lack thereof)<br />
    in its arguments.<br />
<br />
    The C div() and ldiv() functions are interesting, because they are the<br />
    only case where a C library function returns a class object by value.<br />
    Since the C++ type div_t must be different from the underlying C type<br />
    (which is in the wrong namespace) the underlying functions div() and<br />
    ldiv() cannot be re-used efficiently. Fortunately they are trivial to<br />
    re-implement.<br />
<br />
    Chapter 27  Iostreams<br />
    ---------------------<br />
    Headers: &lt;iosfwd&gt; &lt;streambuf&gt; &lt;ios&gt; &lt;ostream&gt; &lt;istream&gt; &lt;iostream&gt;<br />
    &lt;iomanip&gt; &lt;sstream&gt; &lt;fstream&gt;<br />
    C headers: &lt;cstdio&gt; &lt;cwchar&gt; (also in 21)<br />
<br />
    Iostream is currently in a very incomplete state. &lt;iosfwd&gt;, &lt;iomanip&gt;,<br />
    ios_base, and basic_ios&lt;&gt; are "mostly complete". basic_streambuf&lt;&gt; and<br />
    basic_ostream&lt;&gt; are well along, but basic_istream&lt;&gt; has had little work<br />
    done. The standard stream objects, &lt;sstream&gt; and &lt;fstream&gt; have been<br />
    started; basic_filebuf&lt;&gt; "write" functions have been implemented just<br />
    enough to do "hello, world".<br />
<br />
    Most of the istream and ostream operators &lt;&lt; and &gt;&gt; (with the exception<br />
    of the op&lt;&lt;(integer) ones) have not been changed to use locale primitives,<br />
    sentry objects, or char_traits members.<br />
<br />
    All these templates should be manually instantiated for char and<br />
    wchar_t in a way that links only used members into user programs.<br />
<br />
    Streambuf is fertile ground for optimization extensions. An extended<br />
    interface giving iterator access to its internal buffer would be very<br />
    useful for other library components.<br />
<br />
    Iostream operations (primarily operators &lt;&lt; and &gt;&gt;) can take advantage<br />
    of the case where user code has not specified a locale, and bypass locale<br />
    operations entirely. The current implementation of op&lt;&lt;/num_put&lt;&gt;::put,<br />
    for the integer types, demonstrates how they can cache encoding details<br />
    from the locale on each operation. There is lots more room for<br />
    optimization in this area.<br />
<br />
    The definition of the relationship between the standard streams<br />
    cout et al. and stdout et al. requires something like a "stdiobuf".<br />
    The SGI solution of using double-indirection to actually use a<br />
    stdio FILE object for buffering is unsatisfactory, because it<br />
    interferes with peephole loop optimizations.<br />
<br />
    The &lt;sstream&gt; header work has begun. stringbuf can benefit from<br />
    friendship with basic_string&lt;&gt; and basic_string&lt;&gt;::_Rep to use<br />
    those objects directly as buffers, and avoid allocating and making<br />
    copies.<br />
<br />
    The basic_filebuf&lt;&gt; template is a complex beast. It is specified to<br />
    use the locale facet codecvt&lt;&gt; to translate characters between native<br />
    files and the locale character encoding. In general this involves<br />
    two buffers, one of "char" representing the file and another of<br />
    "char_type", for the stream, with codecvt&lt;&gt; translating. The process<br />
    is complicated by the variable-length nature of the translation, and<br />
    the need to seek to corresponding places in the two representations.<br />
    For the case of basic_filebuf&lt;char&gt;, when no translation is needed,<br />
    a single buffer suffices. A specialized filebuf can be used to reduce<br />
    code space overhead when no locale has been imbued. Matt Austern's<br />
    work at SGI will be useful, perhaps directly as a source of code, or<br />
    at least as an example to draw on.<br />
<br />
    Filebuf, almost uniquely (cf. operator new), depends heavily on<br />
    underlying environmental facilities. In current releases iostream<br />
    depends fairly heavily on libio constant definitions, but it should<br />
    be made independent.  It also depends on operating system primitives<br />
    for file operations. There is immense room for optimizations using<br />
    (e.g.) mmap for reading. The shadow/ directory wraps, besides the<br />
    standard C headers, the libio.h and unistd.h headers, for use mainly<br />
    by filebuf. These wrappings have not been completed, though there<br />
    is scaffolding in place.<br />
<br />
    The encapulation of certain C header &lt;cstdio&gt; names presents an<br />
    interesting problem. It is possible to define an inline std::fprintf()<br />
    implemented in terms of the 'extern "C"' vfprintf(), but there is no<br />
    standard vfscanf() to use to implement std::fscanf(). It appears that<br />
    vfscanf but be re-implemented in C++ for targets where no vfscanf<br />
    extension has been defined. This is interesting in that it seems<br />
    to be the only significant case in the C library where this kind of<br />
    rewriting is necessary. (Of course Glibc provides the vfscanf()<br />
    extension.)  (The functions related to exit() must be rewritten<br />
    for other reasons.)<br />
<br />
<br />
    Annex D<br />
    -------<br />
    Headers: &lt;strstream&gt;<br />
<br />
    Annex D defines many non-library features, and many minor<br />
    modifications to various headers, and a complete header.<br />
    It is "mostly done", except that the libstdc++-2 &lt;strstream&gt;<br />
    header has not been adopted into the library, or checked to<br />
    verify that it matches the draft in those details that were<br />
    clarified by the committee. Certainly it must at least be<br />
    moved into the std namespace.<br />
<br />
    We still need to wrap all the deprecated features in #if guards<br />
    so that pedantic compile modes can detect their use.<br />
<br />
    Nonstandard Extensions<br />
    ----------------------<br />
    Headers: &lt;iostream.h&gt; &lt;strstream.h&gt; &lt;hash&gt; &lt;rbtree&gt;<br />
    &lt;pthread_alloc&gt; &lt;stdiobuf&gt; (etc.)<br />
<br />
    User code has come to depend on a variety of nonstandard components<br />
    that we must not omit. Much of this code can be adopted from<br />
    libstdc++-v2 or from the SGI STL. This particularly includes<br />
    &lt;iostream.h&gt;, &lt;strstream.h&gt;, and various SGI extensions such<br />
    as &lt;hash_map.h&gt;. Many of these are already placed in the<br />
    subdirectories ext/ and backward/. (Note that it is better to<br />
    include them via "&lt;backward/hash_map.h&gt;" or "&lt;ext/hash_map&gt;" than<br />
    to search the subdirectory itself via a "-I" directive.<br />
  </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01apas04.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_contributing.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="appendix_porting.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Documentation Style </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix B. Porting and Maintenance</td></tr></table></div></body></html>

41
libstdc++-v3/doc/html/manual/bk01apd.html Normal file
View File

@ -0,0 +1,41 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Appendix D. GNU General Public License</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="appendix_free.html" title="Appendix C. Free Software Needs Free Documentation" /><link rel="next" href="bk01apds02.html" title="TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix D. GNU General Public License</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="appendix_free.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="bk01apds02.html">Next</a></td></tr></table><hr /></div><div class="appendix" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="appendix.gpl-2.0"></a>GNU General Public License</h1></div><div><p class="releaseinfo">Version 2, June 1991</p></div><div><p class="copyright">Copyright © 1989, 1991 Free Software Foundation, Inc.</p></div><div><div class="legalnotice"><a id="gpl-legalnotice"></a><p>
</p><div class="address"><p>Free Software Foundation, Inc. <br />
  <span class="street">51 Franklin Street, Fifth Floor</span>, <br />
  <span class="city">Boston</span>, <span class="state">MA</span> <span class="postcode">02110-1301</span><br />
  <span class="country">USA</span><br />
</p></div><p>
</p><p>Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.</p></div></div><div><p class="pubdate">Version 2, June 1991</p></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="bk01apd.html#gpl-1">Preamble</a></span></dt><dt><span class="section"><a href="bk01apds02.html">TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION</a></span></dt><dd><dl><dt><span class="section"><a href="bk01apds02.html#gpl-2-0">Section 0</a></span></dt><dt><span class="section"><a href="bk01apds02.html#gpl-2-1">Section 1</a></span></dt><dt><span class="section"><a href="bk01apds02.html#gpl-2-2">Section 2</a></span></dt><dt><span class="section"><a href="bk01apds02.html#gpl-2-3">Section 3</a></span></dt><dt><span class="section"><a href="bk01apds02.html#gpl-2-4">Section 4</a></span></dt><dt><span class="section"><a href="bk01apds02.html#gpl-2-5">Section 5</a></span></dt><dt><span class="section"><a href="bk01apds02.html#gpl-2-6">Section 6</a></span></dt><dt><span class="section"><a href="bk01apds02.html#gpl-2-7">Section 7</a></span></dt><dt><span class="section"><a href="bk01apds02.html#gpl-2-8">Section 8</a></span></dt><dt><span class="section"><a href="bk01apds02.html#gpl-2-9">Section 9</a></span></dt><dt><span class="section"><a href="bk01apds02.html#gpl-2-10">Section 10</a></span></dt><dt><span class="section"><a href="bk01apds02.html#gpl-2-11">NO WARRANTY Section 11</a></span></dt><dt><span class="section"><a href="bk01apds02.html#gpl-2-12">Section 12</a></span></dt></dl></dd><dt><span class="section"><a href="bk01apds03.html">How to Apply These Terms to Your New Programs</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="gpl-1"></a>Preamble</h2></div></div></div><p>The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public License is
intended to guarantee your freedom to share and change
free software - to make sure the software is free for all its users.
This General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit
to using it. (Some other Free Software Foundation software is covered
by the GNU Library General Public License instead.) You can apply it
to your programs, too.</p><p>When we speak of free software, we are referring to freedom, not price.
Our General Public Licenses are designed to make sure that you have the
freedom to distribute copies of free software (and charge for this
service if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new free
programs; and that you know you can do these things.</p><p>To protect your rights, we need to make restrictions that forbid anyone
to deny you these rights or to ask you to surrender the rights. These
restrictions translate to certain responsibilities for you if you distribute
copies of the software, or if you modify it.</p><p>For example, if you distribute copies of such a program, whether gratis or
for a fee, you must give the recipients all the rights that you have. You
must make sure that they, too, receive or can get the source code. And you
must show them these terms so they know their rights.</p><p>We protect your rights with two steps:
</p><div class="orderedlist"><ol type="1"><li><p>copyright the software, and</p></li><li><p>offer you this license which gives you legal permission to copy,
distribute and/or modify the software.</p></li></ol></div><p>
</p><p>Also, for each author's protection and ours, we want to make certain that
everyone understands that there is no warranty for this free software. If
the software is modified by someone else and passed on, we want its
recipients to know that what they have is not the original, so that any
problems introduced by others will not reflect on the original authors'
reputations.</p><p>Finally, any free program is threatened constantly by software patents.
We wish to avoid the danger that redistributors of a free program will
individually obtain patent licenses, in effect making the program
proprietary. To prevent this, we have made it clear that any patent must be
licensed for everyone's free use or not licensed at all.</p><p>The precise terms and conditions for copying, distribution and modification
follow.</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="appendix_free.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01apds02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Appendix C. Free Software Needs Free Documentation </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION</td></tr></table></div></body></html>

129
libstdc++-v3/doc/html/manual/bk01apds02.html Normal file
View File

@ -0,0 +1,129 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01apd.html" title="Appendix D. GNU General Public License" /><link rel="prev" href="bk01apd.html" title="Appendix D. GNU General Public License" /><link rel="next" href="bk01apds03.html" title="How to Apply These Terms to Your New Programs" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01apd.html">Prev</a> </td><th width="60%" align="center">Appendix D. GNU General Public License</th><td width="20%" align="right"> <a accesskey="n" href="bk01apds03.html">Next</a></td></tr></table><hr /></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="gpl-2"></a>TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION</h2></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-0"></a>Section 0</h3></div></div></div><p>This License applies to any program or other work which contains a notice
placed by the copyright holder saying it may be distributed under the terms
of this General Public License. The “<span class="quote">Program</span>”, below, refers to any such
program or work, and a
“<span class="quote">work based on the Program</span>” means either
the Program or any derivative work under copyright law: that is to say, a
work containing the Program or a portion of it, either verbatim or with
modifications and/or translated into another language. (Hereinafter, translation
is included without limitation in the term
“<span class="quote">modification</span>”.) Each licensee is addressed as “<span class="quote">you</span>”.</p><p>Activities other than copying, distribution and modification are not covered by
this License; they are outside its scope. The act of running the Program is not
restricted, and the output from the Program is covered only if its contents
constitute a work based on the Program (independent of having been made by running
the Program). Whether that is true depends on what the Program does.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-1"></a>Section 1</h3></div></div></div><p>You may copy and distribute verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and appropriately
publish on each copy an appropriate copyright notice and disclaimer of warranty;
keep intact all the notices that refer to this License and to the absence of any
warranty; and give any other recipients of the Program a copy of this License
along with the Program.</p><p>You may charge a fee for the physical act of transferring a copy, and you may at
your option offer warranty protection in exchange for a fee.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-2"></a>Section 2</h3></div></div></div><p>You may modify your copy or copies of the Program or any portion of it, thus
forming a work based on the Program, and copy and distribute such modifications
or work under the terms of
<a class="link" href="bk01apds02.html#gpl-2-1" title="Section 1">Section 1</a> above, provided
that you also meet all of these conditions:
</p><div class="orderedlist"><ol type="a"><li><p>You must cause the modified files to carry prominent notices stating that
you changed the files and the date of any change.</p></li><li><p>You must cause any work that you distribute or publish, that in whole or
in part contains or is derived from the Program or any part thereof, to be
licensed as a whole at no charge to all third parties under the terms of
this License.</p></li><li><p>If the modified program normally reads commands interactively when run, you
must cause it, when started running for such interactive use in the most
ordinary way, to print or display an announcement including an appropriate
copyright notice and a notice that there is no warranty (or else, saying
that you provide a warranty) and that users may redistribute the program
under these conditions, and telling the user how to view a copy of this
License. (Exception: If the Program itself is interactive but does not
normally print such an announcement, your work based on the Program is not
required to print an announcement.)</p></li></ol></div><p>
</p><p>These requirements apply to the modified work as a whole. If identifiable sections
of that work are not derived from the Program, and can be reasonably considered
independent and separate works in themselves, then this License, and its terms,
do not apply to those sections when you distribute them as separate works. But when
you distribute the same sections as part of a whole which is a work based on the
Program, the distribution of the whole must be on the terms of this License, whose
permissions for other licensees extend to the entire whole, and thus to each and
every part regardless of who wrote it.</p><p>Thus, it is not the intent of this section to claim rights or contest your rights
to work written entirely by you; rather, the intent is to exercise the right to control
the distribution of derivative or collective works based on the Program.</p><p>In addition, mere aggregation of another work not based on the Program with the Program
(or with a work based on the Program) on a volume of a storage or distribution medium
does not bring the other work under the scope of this License.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-3"></a>Section 3</h3></div></div></div><p>You may copy and distribute the Program (or a work based on it, under
<a class="link" href="bk01apds02.html#gpl-2-2" title="Section 2">Section 2</a> in object code or executable form under the terms of
<a class="link" href="bk01apds02.html#gpl-2-1" title="Section 1">Sections 1</a> and
<a class="link" href="bk01apds02.html#gpl-2-2" title="Section 2">2</a> above provided that you also do one of the following:
</p><div class="orderedlist"><ol type="a"><li><p>Accompany it with the complete corresponding machine-readable source code, which
must be distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,</p></li><li><p>Accompany it with a written offer, valid for at least three years, to give any
third party, for a charge no more than your cost of physically performing source
distribution, a complete machine-readable copy of the corresponding source code,
to be distributed under the terms of Sections 1 and 2 above on a medium customarily
used for software interchange; or,</p></li><li><p>Accompany it with the information you received as to the offer to distribute
corresponding source code. (This alternative is allowed only for noncommercial
distribution and only if you received the program in object code or executable form
with such an offer, in accord with Subsection b above.)</p></li></ol></div><p>
</p><p>The source code for a work means the preferred form of the work for making modifications
to it. For an executable work, complete source code means all the source code for all modules
it contains, plus any associated interface definition files, plus the scripts used to control
compilation and installation of the executable. However, as a special exception, the source
code distributed need not include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on) of the operating system
on which the executable runs, unless that component itself accompanies the executable.</p><p>If distribution of executable or object code is made by offering access to copy from a
designated place, then offering equivalent access to copy the source code from the same place
counts as distribution of the source code, even though third parties are not compelled to
copy the source along with the object code.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-4"></a>Section 4</h3></div></div></div><p>You may not copy, modify, sublicense, or distribute the Program except as expressly provided
under this License. Any attempt otherwise to copy, modify, sublicense or distribute the
Program is void, and will automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this License will not have their
licenses terminated so long as such parties remain in full compliance.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-5"></a>Section 5</h3></div></div></div><p>You are not required to accept this License, since you have not signed it. However, nothing
else grants you permission to modify or distribute the Program or its derivative works.
These actions are prohibited by law if you do not accept this License. Therefore, by modifying
or distributing the Program (or any work based on the Program), you indicate your acceptance
of this License to do so, and all its terms and conditions for copying, distributing or
modifying the Program or works based on it.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-6"></a>Section 6</h3></div></div></div><p>Each time you redistribute the Program (or any work based on the Program), the recipient
automatically receives a license from the original licensor to copy, distribute or modify
the Program subject to these terms and conditions. You may not impose any further restrictions
on the recipients' exercise of the rights granted herein. You are not responsible for enforcing
compliance by third parties to this License.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-7"></a>Section 7</h3></div></div></div><p>If, as a consequence of a court judgment or allegation of patent infringement or for any other
reason (not limited to patent issues), conditions are imposed on you (whether by court order,
agreement or otherwise) that contradict the conditions of this License, they do not excuse you
from the conditions of this License. If you cannot distribute so as to satisfy simultaneously
your obligations under this License and any other pertinent obligations, then as a consequence
you may not distribute the Program at all. For example, if a patent license would not permit
royalty-free redistribution of the Program by all those who receive copies directly or
indirectly through you, then the only way you could satisfy both it and this License would be
to refrain entirely from distribution of the Program.</p><p>If any portion of this section is held invalid or unenforceable under any particular circumstance,
the balance of the section is intended to apply and the section as a whole is intended to apply
in other circumstances.</p><p>It is not the purpose of this section to induce you to infringe any patents or other property
right claims or to contest validity of any such claims; this section has the sole purpose of
protecting the integrity of the free software distribution system, which is implemented by public
license practices. Many people have made generous contributions to the wide range of software
distributed through that system in reliance on consistent application of that system; it is up
to the author/donor to decide if he or she is willing to distribute software through any other
system and a licensee cannot impose that choice.</p><p>This section is intended to make thoroughly clear what is believed to be a consequence of the
rest of this License.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-8"></a>Section 8</h3></div></div></div><p>If the distribution and/or use of the Program is restricted in certain countries either by patents
or by copyrighted interfaces, the original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding those countries, so that
distribution is permitted only in or among countries not thus excluded. In such case, this License
incorporates the limitation as if written in the body of this License.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-9"></a>Section 9</h3></div></div></div><p>The Free Software Foundation may publish revised and/or new versions of the General Public License
from time to time. Such new versions will be similar in spirit to the present version, but may differ
in detail to address new problems or concerns.</p><p>Each version is given a distinguishing version number. If the Program specifies a version number of
this License which applies to it and “<span class="quote">any later version</span>”, you have the option of following the terms
and conditions either of that version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of this License, you may choose any
version ever published by the Free Software Foundation.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-10"></a>Section 10</h3></div></div></div><p>If you wish to incorporate parts of the Program into other free programs whose distribution
conditions are different, write to the author to ask for permission. For software which is copyrighted
by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions
for this. Our decision will be guided by the two goals of preserving the free status of all
derivatives of our free software and of promoting the sharing and reuse of software generally.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-11"></a>NO WARRANTY Section 11</h3></div></div></div><p>BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT
PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE PROGRAM “<span class="quote">AS IS</span>” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="gpl-2-12"></a>Section 12</h3></div></div></div><p>IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR
ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED
INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH
ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.</p><p>END OF TERMS AND CONDITIONS</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01apd.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01apd.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01apds03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Appendix D. GNU General Public License </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> How to Apply These Terms to Your New Programs</td></tr></table></div></body></html>

32
libstdc++-v3/doc/html/manual/bk01apds03.html Normal file
View File

@ -0,0 +1,32 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>How to Apply These Terms to Your New Programs</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01apd.html" title="Appendix D. GNU General Public License" /><link rel="prev" href="bk01apds02.html" title="TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION" /><link rel="next" href="bk01ape.html" title="Appendix E. GNU Free Documentation License" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">How to Apply These Terms to Your New Programs</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01apds02.html">Prev</a> </td><th width="60%" align="center">Appendix D. GNU General Public License</th><td width="20%" align="right"> <a accesskey="n" href="bk01ape.html">Next</a></td></tr></table><hr /></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="gpl-3"></a>How to Apply These Terms to Your New Programs</h2></div></div></div><p>If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.</p><p>To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the “<span class="quote">copyright</span>” line and a pointer to where the full notice is found.</p><p>&lt;one line to give the program's name and a brief idea of what it does.&gt;
Copyright (C) &lt;year&gt; &lt;name of author&gt;</p><p>This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.</p><p>This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.</p><p>You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA</p><p>Also add information on how to contact you by electronic and paper mail.</p><p>If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:</p><p>Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type “<span class="quote">show w</span>”.
This is free software, and you are welcome to redistribute it
under certain conditions; type “<span class="quote">show c</span>” for details.</p><p>The hypothetical commands “<span class="quote">show w</span>” and “<span class="quote">show c</span>” should
show the appropriate parts of the General Public License. Of course, the commands you
use may be called something other than “<span class="quote">show w</span>” and “<span class="quote">show c</span>”;
they could even be mouse-clicks or menu items--whatever suits your program.</p><p>You should also get your employer (if you work as a programmer) or your
school, if any, to sign a “<span class="quote">copyright disclaimer</span>” for the program, if
necessary. Here is a sample; alter the names:</p><p>Yoyodyne, Inc., hereby disclaims all copyright interest in the program
“<span class="quote">Gnomovision</span>” (which makes passes at compilers) written by James Hacker.</p><p>&lt;signature of Ty Coon&gt;, 1 April 1989
Ty Coon, President of Vice</p><p>This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01apds02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01apd.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01ape.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix E. GNU Free Documentation License</td></tr></table></div></body></html>

393
libstdc++-v3/doc/html/manual/bk01ape.html Normal file
View File

@ -0,0 +1,393 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Appendix E. GNU Free Documentation License</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="bk01apds03.html" title="How to Apply These Terms to Your New Programs" /><link rel="next" href="../bk02.html" title="" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix E. GNU Free Documentation License</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01apds03.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="../bk02.html">Next</a></td></tr></table><hr /></div><div class="appendix" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="appendix.gfdl-1.2"></a>Appendix E. GNU Free Documentation License</h2></div></div></div><p>
Copyright (C) 2000, 2001, 2002 Free Software Foundation,
<abbr class="abbrev">Inc.</abbr> 51 Franklin <abbr class="abbrev">St</abbr>, Fifth Floor,
Boston, <abbr class="abbrev">MA</abbr> 02110-1301 <abbr class="abbrev">USA</abbr>. Everyone is permitted to copy and
distribute verbatim copies of this license document, but changing it is
not allowed.
</p><h2><a id="Preamble"></a>
0. PREAMBLE
</h2><p>
The purpose of this License is to make a manual, textbook, or other
functional and useful document "free" in the sense of freedom: to assure
everyone the effective freedom to copy and redistribute it, with or
without modifying it, either commercially or noncommercially.
Secondarily, this License preserves for the author and publisher a way to
get credit for their work, while not being considered responsible for
modifications made by others.
</p><p>
This License is a kind of "copyleft", which means that derivative works of
the document must themselves be free in the same sense. It complements
the GNU General Public License, which is a copyleft license designed for
free software.
</p><p>
We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free program
should come with manuals providing the same freedoms that the software
does. But this License is not limited to software manuals; it can be used
for any textual work, regardless of subject matter or whether it is
published as a printed book. We recommend this License principally for
works whose purpose is instruction or reference.</p><h2><a id="Definitions"></a>
1. APPLICABILITY AND DEFINITIONS
</h2><p>
This License applies to any manual or other work, in any medium, that
contains a notice placed by the copyright holder saying it can be
distributed under the terms of this License. Such a notice grants a
world-wide, royalty-free license, unlimited in duration, to use that work
under the conditions stated herein. The "Document", below, refers to any
such manual or work. Any member of the public is a licensee, and is
addressed as "you". You accept the license if you copy, modify or
distribute the work in a way requiring permission under copyright
law.
</p><p>
A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with modifications
and/or translated into another language.
</p><p>
A "Secondary Section" is a named appendix or a front-matter section of the
Document that deals exclusively with the relationship of the publishers or
authors of the Document to the Document's overall subject (or to related
matters) and contains nothing that could fall directly within that overall
subject. (Thus, if the Document is in part a textbook of mathematics, a
Secondary Section may not explain any mathematics.) The relationship
could be a matter of historical connection with the subject or with
related matters, or of legal, commercial, philosophical, ethical or
political position regarding them.
</p><p>
The "Invariant Sections" are certain Secondary Sections whose titles are
designated, as being those of Invariant Sections, in the notice that says
that the Document is released under this License. If a section does not
fit the above definition of Secondary then it is not allowed to be
designated as Invariant. The Document may contain zero Invariant
Sections. If the Document does not identify any Invariant Sections then
there are none.
</p><p>
The "Cover Texts" are certain short passages of text that are listed, as
Front-Cover Texts or Back-Cover Texts, in the notice that says that the
Document is released under this License. A Front-Cover Text may be at
most 5 words, and a Back-Cover Text may be at most 25 words.
</p><p>
A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the general
public, that is suitable for revising the document straightforwardly with
generic text editors or (for images composed of pixels) generic paint
programs or (for drawings) some widely available drawing editor, and that
is suitable for input to text formatters or for automatic translation to a
variety of formats suitable for input to text formatters. A copy made in
an otherwise Transparent file format whose markup, or absence of markup,
has been arranged to thwart or discourage subsequent modification by
readers is not Transparent. An image format is not Transparent if used
for any substantial amount of text. A copy that is not "Transparent" is
called "Opaque".
</p><p>
Examples of suitable formats for Transparent copies include plain ASCII
without markup, Texinfo input format, LaTeX input format, SGML or XML
using a publicly available DTD, and standard-conforming simple HTML,
PostScript or PDF designed for human modification. Examples of
transparent image formats include PNG, XCF and JPG. Opaque formats
include proprietary formats that can be read and edited only by
proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the machine-generated
HTML, PostScript or PDF produced by some word processors for output
purposes only.
</p><p>
The "Title Page" means, for a printed book, the title page itself, plus
such following pages as are needed to hold, legibly, the material this
License requires to appear in the title page. For works in formats which
do not have any title page as such, "Title Page" means the text near the
most prominent appearance of the work's title, preceding the beginning of
the body of the text.
</p><p>
A section "Entitled XYZ" means a named subunit of the Document whose title
either is precisely XYZ or contains XYZ in parentheses following text that
translates XYZ in another language. (Here XYZ stands for a specific
section name mentioned below, such as "Acknowledgements", "Dedications",
"Endorsements", or "History".) To "Preserve the Title" of such a section
when you modify the Document means that it remains a section "Entitled
XYZ" according to this definition.
</p><p>
The Document may include Warranty Disclaimers next to the notice which
states that this License applies to the Document. These Warranty
Disclaimers are considered to be included by reference in this License,
but only as regards disclaiming warranties: any other implication that
these Warranty Disclaimers may have is void and has no effect on the
meaning of this License.
</p><h2><a id="VerbatimCopying"></a>
2. VERBATIM COPYING
</h2><p>
You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the copyright
notices, and the license notice saying this License applies to the
Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License. You may not use technical
measures to obstruct or control the reading or further copying of the
copies you make or distribute. However, you may accept compensation in
exchange for copies. If you distribute a large enough number of copies
you must also follow the conditions in section 3.
</p><p>
You may also lend copies, under the same conditions stated above, and you
may publicly display copies.
</p><h2><a id="QuantityCopying"></a>
3. COPYING IN QUANTITY
</h2><p>
If you publish printed copies (or copies in media that commonly have
printed covers) of the Document, numbering more than 100, and the
Document's license notice requires Cover Texts, you must enclose the
copies in covers that carry, clearly and legibly, all these Cover Texts:
Front-Cover Texts on the front cover, and Back-Cover Texts on the back
cover. Both covers must also clearly and legibly identify you as the
publisher of these copies. The front cover must present the full title
with all words of the title equally prominent and visible. You may add
other material on the covers in addition. Copying with changes limited to
the covers, as long as they preserve the title of the Document and satisfy
these conditions, can be treated as verbatim copying in other
respects.
</p><p>
If the required texts for either cover are too voluminous to fit legibly,
you should put the first ones listed (as many as fit reasonably) on the
actual cover, and continue the rest onto adjacent pages.
</p><p>
If you publish or distribute Opaque copies of the Document numbering more
than 100, you must either include a machine-readable Transparent copy
along with each Opaque copy, or state in or with each Opaque copy a
computer-network location from which the general network-using public has
access to download using public-standard network protocols a complete
Transparent copy of the Document, free of added material. If you use the
latter option, you must take reasonably prudent steps, when you begin
distribution of Opaque copies in quantity, to ensure that this Transparent
copy will remain thus accessible at the stated location until at least one
year after the last time you distribute an Opaque copy (directly or
through your agents or retailers) of that edition to the public.
</p><p>
It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give
them a chance to provide you with an updated version of the
Document.
</p><h2><a id="Modifications"></a>
4. MODIFICATIONS
</h2><p>
You may copy and distribute a Modified Version of the Document under the
conditions of sections 2 and 3 above, provided that you release the
Modified Version under precisely this License, with the Modified Version
filling the role of the Document, thus licensing distribution and
modification of the Modified Version to whoever possesses a copy of it.
In addition, you must do these things in the Modified Version:
</p><div class="orderedlist"><ol type="A"><li>
Use in the Title Page (and on the covers, if any) a title distinct
from that of the Document, and from those of previous versions (which
should, if there were any, be listed in the History section of the
Document). You may use the same title as a previous version if the
original publisher of that version gives permission.
</li><li>
List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has fewer than five),
unless they release you from this requirement.
</li><li>
State on the Title page the name of the publisher of the Modified
Version, as the publisher.
</li><li>
Preserve all the copyright notices of the Document.
</li><li>
Add an appropriate copyright notice for your modifications adjacent to
the other copyright notices.
</li><li>
Include, immediately after the copyright notices, a license notice
giving the public permission to use the Modified Version under the
terms of this License, in the form shown in the Addendum below.
</li><li>
Preserve in that license notice the full lists of Invariant Sections
and required Cover Texts given in the Document's license notice.
</li><li>
Include an unaltered copy of this License.
</li><li>
Preserve the section Entitled "History", Preserve its Title, and add
to it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If
there is no section Entitled "History" in the Document, create one
stating the title, year, authors, and publisher of the Document as
given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
</li><li>
Preserve the network location, if any, given in the Document for
public access to a Transparent copy of the Document, and likewise the
network locations given in the Document for previous versions it was
based on. These may be placed in the "History" section. You may omit
a network location for a work that was published at least four years
before the Document itself, or if the original publisher of the
version it refers to gives permission.
</li><li>
For any section Entitled "Acknowledgements" or "Dedications", Preserve
the Title of the section, and preserve in the section all the
substance and tone of each of the contributor acknowledgements and/or
dedications given therein.
</li><li>
Preserve all the Invariant Sections of the Document, unaltered in
their text and in their titles. Section numbers or the equivalent are
not considered part of the section titles.
</li><li>
Delete any section Entitled "Endorsements". Such a section may not be
included in the Modified Version.
</li><li>
Do not retitle any existing section to be Entitled "Endorsements" or
to conflict in title with any Invariant Section.
</li><li>
Preserve any Warranty Disclaimers.
</li></ol></div><p>
If the Modified Version includes new front-matter sections or appendices
that qualify as Secondary Sections and contain no material copied from the
Document, you may at your option designate some or all of these sections
as invariant. To do this, add their titles to the list of Invariant
Sections in the Modified Version's license notice. These titles must be
distinct from any other section titles.
</p><p>
You may add a section Entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various parties--for
example, statements of peer review or that the text has been approved by
an organization as the authoritative definition of a standard.
</p><p>
You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list of
Cover Texts in the Modified Version. Only one passage of Front-Cover Text
and one of Back-Cover Text may be added by (or through arrangements made
by) any one entity. If the Document already includes a cover text for the
same cover, previously added by you or by arrangement made by the same
entity you are acting on behalf of, you may not add another; but you may
replace the old one, on explicit permission from the previous publisher
that added the old one.
</p><p>
The author(s) and publisher(s) of the Document do not by this License give
permission to use their names for publicity for or to assert or imply
endorsement of any Modified Version.
</p><h2><a id="Combining"></a>
5. COMBINING DOCUMENTS
</h2><p>
You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified versions,
provided that you include in the combination all of the Invariant Sections
of all of the original documents, unmodified, and list them all as
Invariant Sections of your combined work in its license notice, and that
you preserve all their Warranty Disclaimers.
</p><p>
The combined work need only contain one copy of this License, and multiple
identical Invariant Sections may be replaced with a single copy. If there
are multiple Invariant Sections with the same name but different contents,
make the title of each such section unique by adding at the end of it, in
parentheses, the name of the original author or publisher of that section
if known, or else a unique number. Make the same adjustment to the
section titles in the list of Invariant Sections in the license notice of
the combined work.
</p><p>
In the combination, you must combine any sections Entitled "History" in
the various original documents, forming one section Entitled "History";
likewise combine any sections Entitled "Acknowledgements", and any
sections Entitled "Dedications". You must delete all sections Entitled
"Endorsements".
</p><h2><a id="Collections"></a>
6. COLLECTIONS OF DOCUMENTS
</h2><p>
You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this
License in the various documents with a single copy that is included in
the collection, provided that you follow the rules of this License for
verbatim copying of each of the documents in all other respects.
</p><p>
You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this
License into the extracted document, and follow this License in all other
respects regarding verbatim copying of that document.
</p><h2><a id="Aggregation"></a>
7. AGGREGATION WITH INDEPENDENT WORKS
</h2><p>
A compilation of the Document or its derivatives with other separate and
independent documents or works, in or on a volume of a storage or
distribution medium, is called an "aggregate" if the copyright resulting
from the compilation is not used to limit the legal rights of the
compilation's users beyond what the individual works permit. When the
Document is included in an aggregate, this License does not apply to the
other works in the aggregate which are not themselves derivative works of
the Document.
</p><p>
If the Cover Text requirement of section 3 is applicable to these copies
of the Document, then if the Document is less than one half of the entire
aggregate, the Document's Cover Texts may be placed on covers that bracket
the Document within the aggregate, or the electronic equivalent of covers
if the Document is in electronic form. Otherwise they must appear on
printed covers that bracket the whole aggregate.
</p><h2><a id="Translation"></a>
8. TRANSLATION
</h2><p>
Translation is considered a kind of modification, so you may distribute
translations of the Document under the terms of section 4. Replacing
Invariant Sections with translations requires special permission from
their copyright holders, but you may include translations of some or all
Invariant Sections in addition to the original versions of these Invariant
Sections. You may include a translation of this License, and all the
license notices in the Document, and any Warranty Disclaimers, provided
that you also include the original English version of this License and the
original versions of those notices and disclaimers. In case of a
disagreement between the translation and the original version of this
License or a notice or disclaimer, the original version will prevail.
</p><p>
If a section in the Document is Entitled "Acknowledgements",
"Dedications", or "History", the requirement (section 4) to Preserve its
Title (section 1) will typically require changing the actual title.
</p><h2><a id="Termination"></a>
9. TERMINATION
</h2><p>
You may not copy, modify, sublicense, or distribute the Document except as
expressly provided for under this License. Any other attempt to copy,
modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However, parties
who have received copies, or rights, from you under this License will not
have their licenses terminated so long as such parties remain in full
compliance.
</p><h2><a id="FutureRevisions"></a>
10. FUTURE REVISIONS OF THIS LICENSE
</h2><p>
The Free Software Foundation may publish new, revised versions of the GNU
Free Documentation License from time to time. Such new versions will be
similar in spirit to the present version, but may differ in detail to
address new problems or concerns. See <a class="ulink" href="http://www.gnu.org/copyleft/" target="_top">http://www.gnu.org/copyleft/</a>.
</p><p>
Each version of the License is given a distinguishing version number. If
the Document specifies that a particular numbered version of this License
"or any later version" applies to it, you have the option of following the
terms and conditions either of that specified version or of any later
version that has been published (not as a draft) by the Free Software
Foundation. If the Document does not specify a version number of this
License, you may choose any version ever published (not as a draft) by the
Free Software Foundation.
</p><h2><a id="HowToUse"></a>
ADDENDUM: How to use this License for your documents
</h2><p>
To use this License in a document you have written, include a copy of the
License in the document and put the following copyright and license
notices just after the title page:
</p><div class="blockquote"><blockquote class="blockquote"><p>
Copyright (C) YEAR YOUR NAME.
</p><p>
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled "GNU Free
Documentation License".
</p></blockquote></div><p>
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
replace the "with...Texts." line with this:
</p><div class="blockquote"><blockquote class="blockquote"><p>
with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
</p></blockquote></div><p>
If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.
</p><p>
If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of free
software license, such as the GNU General Public License, to permit their
use in free software.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01apds03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="../bk02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">How to Apply These Terms to Your New Programs </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>

6131
libstdc++-v3/doc/html/manual/bk01pt01ch01.html Normal file
View File

File diff suppressed because one or more lines are too long

40
libstdc++-v3/doc/html/manual/bk01pt01ch01s02.html Normal file
View File

@ -0,0 +1,40 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>License</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt01ch01.html" title="Chapter 1. Status" /><link rel="prev" href="bk01pt01ch01.html" title="Chapter 1. Status" /><link rel="next" href="bk01pt01ch01s03.html" title="Bugs" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">License</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt01ch01.html">Prev</a> </td><th width="60%" align="center">Chapter 1. Status</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt01ch01s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.status.license"></a>License</h2></div></div></div><p>
There are two licenses affecting GNU libstdc++: one for the code,
and one for the documentation.
</p><p>
There is a license section in the FAQ regarding common <a class="link" href="../faq.html#faq.license" title="License">questions</a>. If you have more
questions, ask the FSF or the <a class="ulink" href="http://gcc.gnu.org/lists.html" target="_top">gcc mailing list</a>.
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.license.gpl"></a>The Code: GPL</h3></div></div></div><p>
The source code is distributed under the <a class="link" href="bk01apd.html" title="Appendix D. GNU General Public License">GNU General Public License version 2</a>,
with the so-called “<span class="quote">Runtime Exception</span>”
as follows (or see any header or implementation file):
</p><div class="literallayout"><p><br />
      As a special exception, you may use this file as part of a free software<br />
      library without restriction.  Specifically, if other files instantiate<br />
      templates or use macros or inline functions from this file, or you compile<br />
      this file and link it with other files to produce an executable, this<br />
      file does not by itself cause the resulting executable to be covered by<br />
      the GNU General Public License.  This exception does not however<br />
      invalidate any other reasons why the executable file might be covered by<br />
      the GNU General Public License.<br />
    </p></div><p>
Hopefully that text is self-explanatory. If it isn't, you need to speak
to your lawyer, or the Free Software Foundation.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.license.fdl"></a>The Documentation: GPL, FDL</h3></div></div></div><p>
The documentation shipped with the library and made available over
the web, excluding the pages generated from source comments, are
copyrighted by the Free Software Foundation, and placed under the
<a class="link" href="bk01ape.html" title="Appendix E. GNU Free Documentation License"> GNU Free Documentation
License version 1.2</a>. There are no Front-Cover Texts, no
Back-Cover Texts, and no Invariant Sections.
</p><p>
For documentation generated by doxygen or other automated tools
via processing source code comments and markup, the original source
code license applies to the generated files. Thus, the doxygen
documents are licensed <a class="link" href="bk01apd.html" title="Appendix D. GNU General Public License">GPL</a>.
</p><p>
If you plan on making copies of the documentation, please let us know.
We can probably offer suggestions.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt01ch01.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt01ch01.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt01ch01s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 1. Status </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Bugs</td></tr></table></div></body></html>

287
libstdc++-v3/doc/html/manual/bk01pt01ch01s03.html Normal file
View File

@ -0,0 +1,287 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Bugs</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt01ch01.html" title="Chapter 1. Status" /><link rel="prev" href="bk01pt01ch01s02.html" title="License" /><link rel="next" href="bk01pt01ch02.html" title="Chapter 2. Setup" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Bugs</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt01ch01s02.html">Prev</a> </td><th width="60%" align="center">Chapter 1. Status</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt01ch02.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.status.bugs"></a>Bugs</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.bugs.impl"></a>Implementation Bugs</h3></div></div></div><p>
Information on known bugs, details on efforts to fix them, and
fixed bugs are all available as part of the GCC bug tracking
system, <a class="ulink" href="http://gcc.gnu.org/bugzilla" target="_top">bugzilla</a>, with the
category set to <code class="literal">libstdc++</code>.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.bugs.iso"></a>Standard Bugs</h3></div></div></div><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.
</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 <span class="emphasis"><em>partial
copy</em></span> of the Issues List. You can read the full version online
at the <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/" target="_top">ISO C++
Committee homepage</a>, linked to on the
<a class="ulink" href="http://gcc.gnu.org/readings.html" target="_top">GCC "Readings"
page</a>. If
you spend a lot of time reading the issues, we recommend downloading
the ZIP file and reading them locally.
</p><p>
(NB: <span class="emphasis"><em>partial copy</em></span> 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
<code class="constant">_GLIBCXX_RESOLVE_LIB_DEFECTS</code> for examples
of style. Note that we usually do not make changes to the
code until an issue has reached <a class="ulink" href="lwg-active.html#DR" target="_top">DR</a> status.
</p><div class="variablelist"><dl><dt><span class="term"><a class="ulink" href="lwg-defects.html#5" target="_top">5</a>:
<span class="emphasis"><em>string::compare specification questionable</em></span>
</span></dt><dd><p>This should be two overloaded functions rather than a single function.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#17" target="_top">17</a>:
<span class="emphasis"><em>Bad bool parsing</em></span>
</span></dt><dd><p>Apparently extracting Boolean values was messed up...
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#19" target="_top">19</a>:
<span class="emphasis"><em>"Noconv" definition too vague</em></span>
</span></dt><dd><p>If <code class="code">codecvt::do_in</code> returns <code class="code">noconv</code> there are
no changes to the values in <code class="code">[to, to_limit)</code>.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#22" target="_top">22</a>:
<span class="emphasis"><em>Member open vs flags</em></span>
</span></dt><dd><p>Re-opening a file stream does <span class="emphasis"><em>not</em></span> clear the state flags.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#25" target="_top">25</a>:
<span class="emphasis"><em>String operator&lt;&lt; uses width() value wrong</em></span>
</span></dt><dd><p>Padding issues.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#48" target="_top">48</a>:
<span class="emphasis"><em>Use of non-existent exception constructor</em></span>
</span></dt><dd><p>An instance of <code class="code">ios_base::failure</code> is constructed instead.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#49" target="_top">49</a>:
<span class="emphasis"><em>Underspecification of ios_base::sync_with_stdio</em></span>
</span></dt><dd><p>The return type is the <span class="emphasis"><em>previous</em></span> state of synchronization.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#50" target="_top">50</a>:
<span class="emphasis"><em>Copy constructor and assignment operator of ios_base</em></span>
</span></dt><dd><p>These members functions are declared <code class="code">private</code> and are
thus inaccessible. Specifying the correct semantics of
"copying stream state" was deemed too complicated.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#60" target="_top">60</a>:
<span class="emphasis"><em>What is a formatted input function?</em></span>
</span></dt><dd><p>This DR made many widespread changes to <code class="code">basic_istream</code>
and <code class="code">basic_ostream</code> all of which have been implemented.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#63" target="_top">63</a>:
<span class="emphasis"><em>Exception-handling policy for unformatted output</em></span>
</span></dt><dd><p>Make the policy consistent with that of formatted input, unformatted
input, and formatted output.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#68" target="_top">68</a>:
<span class="emphasis"><em>Extractors for char* should store null at end</em></span>
</span></dt><dd><p>And they do now. An editing glitch in the last item in the list of
[27.6.1.2.3]/7.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#74" target="_top">74</a>:
<span class="emphasis"><em>Garbled text for codecvt::do_max_length</em></span>
</span></dt><dd><p>The text of the standard was gibberish. Typos gone rampant.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#75" target="_top">75</a>:
<span class="emphasis"><em>Contradiction in codecvt::length's argument types</em></span>
</span></dt><dd><p>Change the first parameter to <code class="code">stateT&amp;</code> and implement
the new effects paragraph.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#83" target="_top">83</a>:
<span class="emphasis"><em>string::npos vs. string::max_size()</em></span>
</span></dt><dd><p>Safety checks on the size of the string should test against
<code class="code">max_size()</code> rather than <code class="code">npos</code>.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#90" target="_top">90</a>:
<span class="emphasis"><em>Incorrect description of operator&gt;&gt; for strings</em></span>
</span></dt><dd><p>The effect contain <code class="code">isspace(c,getloc())</code> which must be
replaced by <code class="code">isspace(c,is.getloc())</code>.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#91" target="_top">91</a>:
<span class="emphasis"><em>Description of operator&gt;&gt; and getline() for string&lt;&gt;
might cause endless loop</em></span>
</span></dt><dd><p>They behave as a formatted input function and as an unformatted
input function, respectively (except that <code class="code">getline</code> is
not required to set <code class="code">gcount</code>).
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#103" target="_top">103</a>:
<span class="emphasis"><em>set::iterator is required to be modifiable, but this allows
modification of keys.</em></span>
</span></dt><dd><p>For associative containers where the value type is the same as
the key type, both <code class="code">iterator</code> and <code class="code">const_iterator
</code> are constant iterators.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#109" target="_top">109</a>:
<span class="emphasis"><em>Missing binders for non-const sequence elements</em></span>
</span></dt><dd><p>The <code class="code">binder1st</code> and <code class="code">binder2nd</code> didn't have an
<code class="code">operator()</code> taking a non-const parameter.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#110" target="_top">110</a>:
<span class="emphasis"><em>istreambuf_iterator::equal not const</em></span>
</span></dt><dd><p>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.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#117" target="_top">117</a>:
<span class="emphasis"><em>basic_ostream uses nonexistent num_put member functions</em></span>
</span></dt><dd><p><code class="code">num_put::put()</code> was overloaded on the wrong types.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#118" target="_top">118</a>:
<span class="emphasis"><em>basic_istream uses nonexistent num_get member functions</em></span>
</span></dt><dd><p>Same as 117, but for <code class="code">num_get::get()</code>.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#129" target="_top">129</a>:
<span class="emphasis"><em>Need error indication from seekp() and seekg()</em></span>
</span></dt><dd><p>These functions set <code class="code">failbit</code> on error now.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#136" target="_top">136</a>:
<span class="emphasis"><em>seekp, seekg setting wrong streams?</em></span>
</span></dt><dd><p><code class="code">seekp</code> should only set the output stream, and
<code class="code">seekg</code> should only set the input stream.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#167" target="_top">167</a>:
<span class="emphasis"><em>Improper use of traits_type::length()</em></span>
</span></dt><dd><p><code class="code">op&lt;&lt;</code> with a <code class="code">const char*</code> was
calculating an incorrect number of characters to write.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#169" target="_top">169</a>:
<span class="emphasis"><em>Bad efficiency of overflow() mandated</em></span>
</span></dt><dd><p>Grow efficiently the internal array object.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#171" target="_top">171</a>:
<span class="emphasis"><em>Strange seekpos() semantics due to joint position</em></span>
</span></dt><dd><p>Quite complex to summarize...
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#181" target="_top">181</a>:
<span class="emphasis"><em>make_pair() unintended behavior</em></span>
</span></dt><dd><p>This function used to take its arguments as reference-to-const, now
it copies them (pass by value).
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#195" target="_top">195</a>:
<span class="emphasis"><em>Should basic_istream::sentry's constructor ever set eofbit?</em></span>
</span></dt><dd><p>Yes, it can, specifically if EOF is reached while skipping whitespace.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#211" target="_top">211</a>:
<span class="emphasis"><em>operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</em></span>
</span></dt><dd><p>If nothing is extracted into the string, <code class="code">op&gt;&gt;</code> now
sets <code class="code">failbit</code> (which can cause an exception, etc., etc.).
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#214" target="_top">214</a>:
<span class="emphasis"><em>set::find() missing const overload</em></span>
</span></dt><dd><p>Both <code class="code">set</code> and <code class="code">multiset</code> were missing
overloaded find, lower_bound, upper_bound, and equal_range functions
for const instances.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#231" target="_top">231</a>:
<span class="emphasis"><em>Precision in iostream?</em></span>
</span></dt><dd><p>For conversion from a floating-point type, <code class="code">str.precision()</code>
is specified in the conversion specification.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-active.html#233" target="_top">233</a>:
<span class="emphasis"><em>Insertion hints in associative containers</em></span>
</span></dt><dd><p>Implement N1780, first check before then check after, insert as close
to hint as possible.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#235" target="_top">235</a>:
<span class="emphasis"><em>No specification of default ctor for reverse_iterator</em></span>
</span></dt><dd><p>The declaration of <code class="code">reverse_iterator</code> lists a default constructor.
However, no specification is given what this constructor should do.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#241" target="_top">241</a>:
<span class="emphasis"><em>Does unique_copy() require CopyConstructible and Assignable?</em></span>
</span></dt><dd><p>Add a helper for forward_iterator/output_iterator, fix the existing
one for input_iterator/output_iterator to not rely on Assignability.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#243" target="_top">243</a>:
<span class="emphasis"><em>get and getline when sentry reports failure</em></span>
</span></dt><dd><p>Store a null character only if the character array has a non-zero size.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#251" target="_top">251</a>:
<span class="emphasis"><em>basic_stringbuf missing allocator_type</em></span>
</span></dt><dd><p>This nested typedef was originally not specified.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#253" target="_top">253</a>:
<span class="emphasis"><em>valarray helper functions are almost entirely useless</em></span>
</span></dt><dd><p>Make the copy constructor and copy-assignment operator declarations
public in gslice_array, indirect_array, mask_array, slice_array; provide
definitions.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#265" target="_top">265</a>:
<span class="emphasis"><em>std::pair::pair() effects overly restrictive</em></span>
</span></dt><dd><p>The default ctor would build its members from copies of temporaries;
now it simply uses their respective default ctors.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#266" target="_top">266</a>:
<span class="emphasis"><em>bad_exception::~bad_exception() missing Effects clause</em></span>
</span></dt><dd><p>The <code class="code">bad_</code>* classes no longer have destructors (they
are trivial), since no description of them was ever given.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#271" target="_top">271</a>:
<span class="emphasis"><em>basic_iostream missing typedefs</em></span>
</span></dt><dd><p>The typedefs it inherits from its base classes can't be used, since
(for example) <code class="code">basic_iostream&lt;T&gt;::traits_type</code> is ambiguous.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#275" target="_top">275</a>:
<span class="emphasis"><em>Wrong type in num_get::get() overloads</em></span>
</span></dt><dd><p>Similar to 118.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#280" target="_top">280</a>:
<span class="emphasis"><em>Comparison of reverse_iterator to const reverse_iterator</em></span>
</span></dt><dd><p>Add global functions with two template parameters.
(NB: not added for now a templated assignment operator)
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#292" target="_top">292</a>:
<span class="emphasis"><em>Effects of a.copyfmt (a)</em></span>
</span></dt><dd><p>If <code class="code">(this == &amp;rhs)</code> do nothing.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#300" target="_top">300</a>:
<span class="emphasis"><em>List::merge() specification incomplete</em></span>
</span></dt><dd><p>If <code class="code">(this == &amp;x)</code> do nothing.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#303" target="_top">303</a>:
<span class="emphasis"><em>Bitset input operator underspecified</em></span>
</span></dt><dd><p>Basically, compare the input character to <code class="code">is.widen(0)</code>
and <code class="code">is.widen(1)</code>.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#305" target="_top">305</a>:
<span class="emphasis"><em>Default behavior of codecvt&lt;wchar_t, char, mbstate_t&gt;::length()</em></span>
</span></dt><dd><p>Do not specify what <code class="code">codecvt&lt;wchar_t, char, mbstate_t&gt;::do_length</code>
must return.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#328" target="_top">328</a>:
<span class="emphasis"><em>Bad sprintf format modifier in money_put&lt;&gt;::do_put()</em></span>
</span></dt><dd><p>Change the format string to "%.0Lf".
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#365" target="_top">365</a>:
<span class="emphasis"><em>Lack of const-qualification in clause 27</em></span>
</span></dt><dd><p>Add const overloads of <code class="code">is_open</code>.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#389" target="_top">389</a>:
<span class="emphasis"><em>Const overload of valarray::operator[] returns by value</em></span>
</span></dt><dd><p>Change it to return a <code class="code">const T&amp;</code>.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#402" target="_top">402</a>:
<span class="emphasis"><em>Wrong new expression in [some_]allocator::construct</em></span>
</span></dt><dd><p>Replace "new" with "::new".
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#409" target="_top">409</a>:
<span class="emphasis"><em>Closing an fstream should clear the error state</em></span>
</span></dt><dd><p>Have <code class="code">open</code> clear the error flags.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-active.html#431" target="_top">431</a>:
<span class="emphasis"><em>Swapping containers with unequal allocators</em></span>
</span></dt><dd><p>Implement Option 3, as per N1599.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#432" target="_top">432</a>:
<span class="emphasis"><em>stringbuf::overflow() makes only one write position
available</em></span>
</span></dt><dd><p>Implement the resolution, beyond DR 169.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#434" target="_top">434</a>:
<span class="emphasis"><em>bitset::to_string() hard to use</em></span>
</span></dt><dd><p>Add three overloads, taking fewer template arguments.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#438" target="_top">438</a>:
<span class="emphasis"><em>Ambiguity in the "do the right thing" clause</em></span>
</span></dt><dd><p>Implement the resolution, basically cast less.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#453" target="_top">453</a>:
<span class="emphasis"><em>basic_stringbuf::seekoff need not always fail for an empty stream</em></span>
</span></dt><dd><p>Don't fail if the next pointer is null and newoff is zero.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#455" target="_top">455</a>:
<span class="emphasis"><em>cerr::tie() and wcerr::tie() are overspecified</em></span>
</span></dt><dd><p>Initialize cerr tied to cout and wcerr tied to wcout.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#464" target="_top">464</a>:
<span class="emphasis"><em>Suggestion for new member functions in standard containers</em></span>
</span></dt><dd><p>Add <code class="code">data()</code> to <code class="code">std::vector</code> and
<code class="code">at(const key_type&amp;)</code> to <code class="code">std::map</code>.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#508" target="_top">508</a>:
<span class="emphasis"><em>Bad parameters for ranlux64_base_01</em></span>
</span></dt><dd><p>Fix the parameters.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-closed.html#512" target="_top">512</a>:
<span class="emphasis"><em>Seeding subtract_with_carry_01 from a single unsigned long</em></span>
</span></dt><dd><p>Construct a <code class="code">linear_congruential</code> engine and seed with it.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-closed.html#526" target="_top">526</a>:
<span class="emphasis"><em>Is it undefined if a function in the standard changes in
parameters?</em></span>
</span></dt><dd><p>Use &amp;value.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#538" target="_top">538</a>:
<span class="emphasis"><em>241 again: Does unique_copy() require CopyConstructible
and Assignable?</em></span>
</span></dt><dd><p>In case of input_iterator/output_iterator rely on Assignability of
input_iterator' value_type.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#541" target="_top">541</a>:
<span class="emphasis"><em>shared_ptr template assignment and void</em></span>
</span></dt><dd><p>Add an auto_ptr&lt;void&gt; specialization.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#543" target="_top">543</a>:
<span class="emphasis"><em>valarray slice default constructor</em></span>
</span></dt><dd><p>Follow the straightforward proposed resolution.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#586" target="_top">586</a>:
<span class="emphasis"><em>string inserter not a formatted function</em></span>
</span></dt><dd><p>Change it to be a formatted output function (i.e. catch exceptions).
</p></dd><dt><span class="term"><a class="ulink" href="lwg-active.html#596" target="_top">596</a>:
<span class="emphasis"><em>27.8.1.3 Table 112 omits "a+" and "a+b" modes</em></span>
</span></dt><dd><p>Add the missing modes to fopen_mode.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#660" target="_top">660</a>:
<span class="emphasis"><em>Missing bitwise operations</em></span>
</span></dt><dd><p>Add the missing operations.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-active.html#693" target="_top">693</a>:
<span class="emphasis"><em>std::bitset::all() missing</em></span>
</span></dt><dd><p>Add it, consistently with the discussion.
</p></dd><dt><span class="term"><a class="ulink" href="lwg-active.html#695" target="_top">695</a>:
<span class="emphasis"><em>ctype&lt;char&gt;::classic_table() not accessible</em></span>
</span></dt><dd><p>Make the member functions table and classic_table public.
</p></dd></dl></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt01ch01s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt01ch01.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt01ch02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">License </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 2. Setup</td></tr></table></div></body></html>

181
libstdc++-v3/doc/html/manual/bk01pt01ch02.html Normal file
View File

@ -0,0 +1,181 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 2. Setup</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="intro.html" title="Part I. Introduction" /><link rel="prev" href="bk01pt01ch01s03.html" title="Bugs" /><link rel="next" href="build.html" title="Build" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 2. Setup</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt01ch01s03.html">Prev</a> </td><th width="60%" align="center">Part I. Introduction</th><td width="20%" align="right"> <a accesskey="n" href="build.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.intro.setup"></a>Chapter 2. Setup</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt01ch02.html#manual.intro.setup.configure">Configure</a></span></dt><dt><span class="sect1"><a href="build.html">Build</a></span></dt><dd><dl><dt><span class="sect2"><a href="build.html#build.prereq">Prerequisites</a></span></dt><dt><span class="sect2"><a href="build.html#build.configure">Make</a></span></dt></dl></dd><dt><span class="sect1"><a href="test.html">Test</a></span></dt><dd><dl><dt><span class="sect2"><a href="test.html#test.organization">Organization</a></span></dt><dt><span class="sect2"><a href="test.html#test.naming">Naming Conventions</a></span></dt><dt><span class="sect2"><a href="test.html#test.utils">Utilities</a></span></dt><dt><span class="sect2"><a href="test.html#test.run">Running the Testsuite</a></span></dt><dt><span class="sect2"><a href="test.html#test.new_tests">New Test Cases</a></span></dt><dt><span class="sect2"><a href="test.html#test.dejagnu">Test Harness Details</a></span></dt><dt><span class="sect2"><a href="test.html#test.future">Future</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.setup.configure"></a>Configure</h2></div></div></div><p>
Here are some of the non-obvious options to libstdc++'s configure.
Keep in mind that
<a class="ulink" href="http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_131.html#SEC131" target="_top">they
all have opposite forms as well</a>
(enable/disable and with/without). The defaults are for <span class="emphasis"><em>current
development sources</em></span>, which may be different than those for
released versions.
</p><p>The canonical way to find out the configure options that are
available for a given set of libstdc++ sources is to go to the
source directory and then type:<code class="code"> ./configure --help</code>
</p><div class="variablelist"><dl><dt><span class="term"><code class="code">--enable-multilib</code>[default]</span></dt><dd><p>This is part of the generic multilib support for building cross
compilers. As such, targets like "powerpc-elf" will have
libstdc++ built many different ways: "-msoft-float"
and not, etc. A different libstdc++ will be built for each of
the different multilib versions. This option is on by default.
</p></dd><dt><span class="term"><code class="code">--enable-sjlj-exceptions</code></span></dt><dd><p>Forces old, set-jump/long-jump exception handling model. If
at all possible, the new, frame unwinding exception handling routines
should be used instead, as they significantly reduce both
runtime memory usage and executable size. This option can
change the library ABI.
</p></dd><dt><span class="term"><code class="code">--enable-version-specific-runtime-libs</code></span></dt><dd><p>Specify that run-time libraries should be installed in the
compiler-specific subdirectory (i.e.,
<code class="code">${libdir}/gcc-lib/${target_alias}/${gcc_version}</code>)
instead of <code class="code">${libdir}</code>. This option is useful if you
intend to use several versions of gcc in parallel. In addition,
libstdc++'s include files will be installed in
<code class="code">${libdir}/gcc-lib/${target_alias}/${gcc_version}/include/g++</code>,
unless you also specify
<code class="literal">--with-gxx-include-dir=<code class="filename">dirname</code></code> during configuration.
</p></dd><dt><span class="term"><code class="code">--with-gxx-include-dir=&lt;include-files dir&gt;</code></span></dt><dd><p>Adds support for named libstdc++ include directory. For instance,
the following puts all the libstdc++ headers into a directory
called "2.97-20001008" instead of the usual
"c++/(version)".
</p><pre class="programlisting">
--with-gxx-include-dir=/foo/H-x86-gcc-3-c-gxx-inc/include/2.97-20001008</pre></dd><dt><span class="term"><code class="code">--enable-cstdio</code></span></dt><dd><p>This is an abbreviated form of <code class="code">'--enable-cstdio=stdio'</code>
(described next). This option can change the library ABI.
</p></dd><dt><span class="term"><code class="code">--enable-cstdio=OPTION</code></span></dt><dd><p>Select a target-specific I/O package. At the moment, the only
choice is to use 'stdio', a generic "C" abstraction.
The default is 'stdio'.
</p></dd><dt><span class="term"><code class="code">--enable-clocale</code></span></dt><dd><p>This is an abbreviated form of <code class="code">'--enable-clocale=generic'</code>
(described next). This option can change the library ABI.
</p></dd><dt><span class="term"><code class="code">--enable-clocale=OPTION</code></span></dt><dd><p>Select a target-specific underlying locale package. The
choices are 'ieee_1003.1-2001' to specify an X/Open, Standard Unix
(IEEE Std. 1003.1-2001) model based on langinfo/iconv/catgets,
'gnu' to specify a model based on functionality from the GNU C
library (langinfo/iconv/gettext) (from <a class="ulink" href="http://sources.redhat.com/glibc/" target="_top">glibc</a>, the GNU C
library), or 'generic' to use a generic "C"
abstraction which consists of "C" locale info.
</p><p>As part of the configuration process, the "C" library is
probed both for sufficient vintage, and installed locale
data. If either of these elements are not present, the C++
locale model default to 'generic.' On glibc-based systems of
version 2.2.5 and above with installed locale files, 'gnu' is
automatically selected.
</p></dd><dt><span class="term"><code class="code">--enable-libstdcxx-allocator</code></span></dt><dd><p>This is an abbreviated form of
<code class="code">'--enable-libstdcxx-allocator=auto'</code> (described
next). This option can change the library ABI.
</p></dd><dt><span class="term"><code class="code">--enable-libstdcxx-allocator=OPTION </code></span></dt><dd><p>Select a target-specific underlying std::allocator. The
choices are 'new' to specify a wrapper for new, 'malloc' to
specify a wrapper for malloc, 'mt' for a fixed power of two allocator
(<a class="ulink" href="ext/mt_allocator.html" target="_top">documented</a> under extensions),
'pool' for the SGI pooled allocator or 'bitmap' for a bitmap allocator.
This option can change the library ABI.
</p></dd><dt><span class="term"><code class="code">--enable-cheaders=OPTION</code></span></dt><dd><p>This allows the user to define the approach taken for C header
compatibility with C++. Options are c, c_std, and c_global.
These correspond to the source directory's include/c,
include/c_std, and include/c_global, and may also include
include/c_compatibility. The default is c_global.
</p></dd><dt><span class="term"><code class="code">--enable-threads</code></span></dt><dd><p>This is an abbreviated form of <code class="code">'--enable-threads=yes'</code>
(described next). This option can change the library ABI.
</p></dd><dt><span class="term"><code class="code">--enable-threads=OPTION</code></span></dt><dd><p>Select a threading library. A full description is given in the
general <a class="ulink" href="http://gcc.gnu.org/install/configure.html" target="_top">compiler
configuration instructions</a>.
</p></dd><dt><span class="term"><code class="code">--enable-libstdcxx-debug</code></span></dt><dd><p>Build separate debug libraries in addition to what is normally built.
By default, the debug libraries are compiled with
<code class="code"> CXXFLAGS='-g3 -O0'</code>
, are installed in <code class="code">${libdir}/debug</code>, and have the
same names and versioning information as the non-debug
libraries. This option is off by default.
</p><p>Note this make command, executed in
the build directory, will do much the same thing, without the
configuration difference and without building everything twice:
<code class="code">make CXXFLAGS='-g3 -O0' all</code>
</p></dd><dt><span class="term"><code class="code">--enable-libstdcxx-debug-flags=FLAGS</code></span></dt><dd><p>This option is only valid when <code class="code"> --enable-debug </code>
is also specified, and applies to the debug builds only. With
this option, you can pass a specific string of flags to the
compiler to use when building the debug versions of libstdc++.
FLAGS is a quoted string of options, like
</p><pre class="programlisting">
--enable-libstdcxx-debug-flags='-g3 -O1 -gdwarf-2'</pre></dd><dt><span class="term"><code class="code">--enable-cxx-flags=FLAGS</code></span></dt><dd><p>With this option, you can pass a string of -f (functionality)
flags to the compiler to use when building libstdc++. This
option can change the library ABI. FLAGS is a quoted string of
options, like
</p><pre class="programlisting">
--enable-cxx-flags='-fvtable-gc -fomit-frame-pointer -ansi'</pre><p>
Note that the flags don't necessarily have to all be -f flags,
as shown, but usually those are the ones that will make sense
for experimentation and configure-time overriding.
</p><p>The advantage of --enable-cxx-flags over setting CXXFLAGS in
the 'make' environment is that, if files are automatically
rebuilt, the same flags will be used when compiling those files
as well, so that everything matches.
</p><p>Fun flags to try might include combinations of
</p><pre class="programlisting">
-fstrict-aliasing
-fno-exceptions
-ffunction-sections
-fvtable-gc</pre><p>and opposite forms (-fno-) of the same. Tell us (the libstdc++
mailing list) if you discover more!
</p></dd><dt><span class="term"><code class="code">--enable-c99</code></span></dt><dd><p>The "long long" type was introduced in C99, along
with many other functions for wide characters, and math
classification macros, etc. If enabled, all C99 functions not
specified by the C++ standard will be put into <code class="code">namespace
__gnu_cxx</code>, and then all these names will
be injected into namespace std, so that C99 functions can be
used "as if" they were in the C++ standard (as they
will eventually be in some future revision of the standard,
without a doubt). By default, C99 support is on, assuming the
configure probes find all the necessary functions and bits
necessary. This option can change the library ABI.
</p></dd><dt><span class="term"><code class="code">--enable-wchar_t</code>[default]</span></dt><dd><p>Template specializations for the "wchar_t" type are
required for wide character conversion support. Disabling
wide character specializations may be expedient for initial
porting efforts, but builds only a subset of what is required by
ISO, and is not recommended. By default, this option is on.
This option can change the library ABI.
</p></dd><dt><span class="term"><code class="code">--enable-long-long </code></span></dt><dd><p>The "long long" type was introduced in C99. It is
provided as a GNU extension to C++98 in g++. This flag builds
support for "long long" into the library (specialized
templates and the like for iostreams). This option is on by default:
if enabled, users will have to either use the new-style "C"
headers by default (i.e., &lt;cmath&gt; not &lt;math.h&gt;)
or add appropriate compile-time flags to all compile lines to
allow "C" visibility of this feature (on GNU/Linux,
the flag is -D_ISOC99_SOURCE, which is added automatically via
CPLUSPLUS_CPP_SPEC's addition of _GNU_SOURCE).
This option can change the library ABI.
</p></dd><dt><span class="term"><code class="code">--enable-fully-dynamic-string</code></span></dt><dd><p>This option enables a special version of basic_string avoiding
the optimization that allocates empty objects in static memory.
Mostly useful together with shared memory allocators, see PR
libstdc++/16612 for details.
</p></dd><dt><span class="term"><code class="code">--enable-concept-checks</code></span></dt><dd><p>This turns on additional compile-time checks for instantiated
library templates, in the form of specialized templates,
<a class="ulink" href="19_diagnostics/howto.html#3" target="_top">described here</a>. They
can help users discover when they break the rules of the STL, before
their programs run.
</p></dd><dt><span class="term"><code class="code">--enable-symvers[=style]</code></span></dt><dd><p>In 3.1 and later, tries to turn on symbol versioning in the
shared library (if a shared library has been
requested). Values for 'style' that are currently supported
are 'gnu', 'gnu-versioned-namespace', 'darwin', and
'darwin-export'. Both gnu- options require that a recent
version of the GNU linker be in use. Both darwin options are
equivalent. With no style given, the configure script will try
to guess correct defaults for the host system, probe to see if
additional requirements are necessary and present for
activation, and if so, will turn symbol versioning on. This
option can change the library ABI.
</p></dd><dt><span class="term"><code class="code">--enable-visibility</code></span></dt><dd><p> In 4.2 and later, enables or disables visibility attributes.
If enabled (as by default), and the compiler seems capable of
passing the simple sanity checks thrown at it, adjusts items
in namespace std, namespace std::tr1, and namespace __gnu_cxx
so that -fvisibility options work.
</p></dd><dt><span class="term"><code class="code">--enable-libstdcxx-pch</code></span></dt><dd><p>In 3.4 and later, tries to turn on the generation of
stdc++.h.gch, a pre-compiled file including all the standard
C++ includes. If enabled (as by default), and the compiler
seems capable of passing the simple sanity checks thrown at
it, try to build stdc++.h.gch as part of the make process.
In addition, this generated file is used later on (by appending <code class="code">
--include bits/stdc++.h </code> to CXXFLAGS) when running the
testsuite.
</p></dd><dt><span class="term"><code class="code">--disable-hosted-libstdcxx</code></span></dt><dd><p>
By default, a complete <span class="emphasis"><em>hosted</em></span> C++ library is
built. The C++ Standard also describes a
<span class="emphasis"><em>freestanding</em></span> environment, in which only a
minimal set of headers are provided. This option builds such an
environment.
</p></dd></dl></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt01ch01s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="intro.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="build.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Bugs </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Build</td></tr></table></div></body></html>

99
libstdc++-v3/doc/html/manual/bk01pt01ch03s02.html Normal file
View File

@ -0,0 +1,99 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Headers</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="using.html" title="Chapter 3. Using" /><link rel="next" href="bk01pt01ch03s03.html" title="Namespaces" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Headers</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="using.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt01ch03s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.headers"></a>Headers</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.headers.all"></a>Header Files</h3></div></div></div><p>
The C++ standard specifies the entire set of header files that
must be available to all hosted implementations. Actually, the
word "files" is a misnomer, since the contents of the
headers don't necessarily have to be in any kind of external
file. The only rule is that when one <code class="code">#include</code>'s a
header, the contents of that header become available, no matter
how.
</p><p>
That said, in practice files are used.
</p><p>
There are two main types of include files: header files related
to a specific version of the ISO C++ standard (called Standard
Headers), and all others (TR1, C++ ABI, and Extensions).
</p><p>
Two dialects of standard headers are supported, corresponding to
the 1998 standard as updated for 2003, and the draft of the
upcoming 200x standard.
</p><p>
C++98/03 include files. These are available in the default compilation mode, ie <code class="code">-std=c++98</code> or <code class="code">-std=gnu++98</code>.
</p><div class="table"><a id="id398035"></a><p class="title"><b>Table 3.1. C++ 1998 Library Headers</b></p><div class="table-contents"><table summary="C++ 1998 Library Headers" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col /></colgroup><tbody><tr><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="filename">iomanip</code></td><td align="left"><code class="filename">list</code></td><td align="left"><code class="filename">ostream</code></td><td align="left"><code class="filename">streambuf</code></td></tr><tr><td align="left"><code class="filename">bitset</code></td><td align="left"><code class="filename">ios</code></td><td align="left"><code class="filename">locale</code></td><td align="left"><code class="filename">queue</code></td><td align="left"><code class="filename">string</code></td></tr><tr><td align="left"><code class="filename">complex</code></td><td align="left"><code class="filename">iosfwd</code></td><td align="left"><code class="filename">map</code></td><td align="left"><code class="filename">set</code></td><td align="left"><code class="filename">typeinfo</code></td></tr><tr><td align="left"><code class="filename">deque</code></td><td align="left"><code class="filename">iostream</code></td><td align="left"><code class="filename">memory</code></td><td align="left"><code class="filename">sstream</code></td><td align="left"><code class="filename">utility</code></td></tr><tr><td align="left"><code class="filename">exception</code></td><td align="left"><code class="filename">istream</code></td><td align="left"><code class="filename">new</code></td><td align="left"><code class="filename">stack</code></td><td align="left"><code class="filename">valarray</code></td></tr><tr><td align="left"><code class="filename">fstream</code></td><td align="left"><code class="filename">iterator</code></td><td align="left"><code class="filename">numeric</code></td><td align="left"><code class="filename">stdexcept</code></td><td align="left"><code class="filename">vector</code></td></tr><tr><td align="left"><code class="filename">functional</code></td><td align="left"><code class="filename">limits</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p></p><div class="table"><a id="id397982"></a><p class="title"><b>Table 3.2. C++ 1998 Library Headers for C Library Facilities</b></p><div class="table-contents"><table summary="C++ 1998 Library Headers for C Library Facilities" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col /></colgroup><tbody><tr><td align="left"><code class="filename">cassert</code></td><td align="left"><code class="filename">ciso646</code></td><td align="left"><code class="filename">csetjmp</code></td><td align="left"><code class="filename">cstdio</code></td><td align="left"><code class="filename">ctime</code></td></tr><tr><td align="left"><code class="filename">cctype</code></td><td align="left"><code class="filename">climits</code></td><td align="left"><code class="filename">csignal</code></td><td align="left"><code class="filename">cstdlib</code></td><td align="left"><code class="filename">cwchar</code></td></tr><tr><td align="left"><code class="filename">cerrno</code></td><td align="left"><code class="filename">clocale</code></td><td align="left"><code class="filename">cstdarg</code></td><td align="left"><code class="filename">cstring</code></td><td align="left"><code class="filename">cwctype</code></td></tr><tr><td align="left"><code class="filename">cfloat</code></td><td align="left"><code class="filename">cmath</code></td><td align="left"><code class="filename">cstddef</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p>C++0x include files. These are only available in C++0x compilation mode, ie <code class="code">-std=c++0x</code> or <code class="code">-std=gnu++0x</code>.
</p><p></p><div class="table"><a id="id399447"></a><p class="title"><b>Table 3.3. C++ 200x Library Headers</b></p><div class="table-contents"><table summary="C++ 200x Library Headers" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col /></colgroup><tbody><tr><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="filename">iomanip</code></td><td align="left"><code class="filename">locale</code></td><td align="left"><code class="filename">regex</code></td><td align="left"><code class="filename">tuple</code></td></tr><tr><td align="left"><code class="filename">array</code></td><td align="left"><code class="filename">ios</code></td><td align="left"><code class="filename">map</code></td><td align="left"><code class="filename">set</code></td><td align="left"><code class="filename">typeinfo</code></td></tr><tr><td align="left"><code class="filename">bitset</code></td><td align="left"><code class="filename">iosfwd</code></td><td align="left"><code class="filename">memory</code></td><td align="left"><code class="filename">sstream</code></td><td align="left"><code class="filename">type_traits</code></td></tr><tr><td align="left"><code class="filename">complex</code></td><td align="left"><code class="filename">iostream</code></td><td align="left"><code class="filename">new</code></td><td align="left"><code class="filename">stack</code></td><td align="left"><code class="filename">unordered_map</code></td></tr><tr><td align="left"><code class="filename">deque</code></td><td align="left"><code class="filename">istream</code></td><td align="left"><code class="filename">numeric</code></td><td align="left"><code class="filename">stdexcept</code></td><td align="left"><code class="filename">unordered_set</code></td></tr><tr><td align="left"><code class="filename">exception</code></td><td align="left"><code class="filename">iterator</code></td><td align="left"><code class="filename">ostream</code></td><td align="left"><code class="filename">streambuf</code></td><td align="left"><code class="filename">utility</code></td></tr><tr><td align="left"><code class="filename">fstream</code></td><td align="left"><code class="filename">limits</code></td><td align="left"><code class="filename">queue</code></td><td align="left"><code class="filename">string</code></td><td align="left"><code class="filename">valarray</code></td></tr><tr><td align="left"><code class="filename">functional</code></td><td align="left"><code class="filename">list</code></td><td align="left"><code class="filename">random</code></td><td align="left"><code class="filename">system_error</code></td><td align="left"><code class="filename">vector</code></td></tr></tbody></table></div></div><br class="table-break" /><p></p><div class="table"><a id="id394222"></a><p class="title"><b>Table 3.4. C++ 200x Library Headers for C Library Facilities</b></p><div class="table-contents"><table summary="C++ 200x Library Headers for C Library Facilities" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">cassert</code></td><td align="left"><code class="filename">cfloat</code></td><td align="left"><code class="filename">cmath</code></td><td align="left"><code class="filename">cstddef</code></td><td align="left"><code class="filename">ctgmath</code></td></tr><tr><td align="left"><code class="filename">ccomplex</code></td><td align="left"><code class="filename">cinttypes</code></td><td align="left"><code class="filename">csetjmp</code></td><td align="left"><code class="filename">cstdint</code></td><td align="left"><code class="filename">ctime</code></td></tr><tr><td align="left"><code class="filename">cctype</code></td><td align="left"><code class="filename">ciso646</code></td><td align="left"><code class="filename">csignal</code></td><td align="left"><code class="filename">cstdio</code></td><td align="left"><code class="filename">cuchar</code></td></tr><tr><td align="left"><code class="filename">cerrno</code></td><td align="left"><code class="filename">climits</code></td><td align="left"><code class="filename">cstdarg</code></td><td align="left"><code class="filename">cstdlib</code></td><td align="left"><code class="filename">cwchar</code></td></tr><tr><td align="left"><code class="filename">cfenv</code></td><td align="left"><code class="filename">clocale</code></td><td align="left"><code class="filename">cstdbool</code></td><td align="left"><code class="filename">cstring</code></td><td align="left"><code class="filename">cwctype</code></td></tr></tbody></table></div></div><br class="table-break" /><p>
In addition, TR1 includes as:
</p><div class="table"><a id="id485624"></a><p class="title"><b>Table 3.5. C++ TR1 Library Headers</b></p><div class="table-contents"><table summary="C++ TR1 Library Headers" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">tr1/array</code></td><td align="left"><code class="filename">tr1/memory</code></td><td align="left"><code class="filename">tr1/regex</code></td><td align="left"><code class="filename">tr1/type_traits</code></td><td align="left"><code class="filename">tr1/unordered_set</code></td></tr><tr><td align="left"><code class="filename">tr1/complex</code></td><td align="left"><code class="filename">tr1/random</code></td><td align="left"><code class="filename">tr1/tuple</code></td><td align="left"><code class="filename">tr1/unordered_map</code></td><td align="left"><code class="filename">tr1/utility</code></td></tr><tr><td align="left"><code class="filename">tr1/functional</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p></p><div class="table"><a id="id407403"></a><p class="title"><b>Table 3.6. C++ TR1 Library Headers for C Library Facilities</b></p><div class="table-contents"><table summary="C++ TR1 Library Headers for C Library Facilities" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">tr1/cmath</code></td><td align="left"><code class="filename">tr1/cfloat</code></td><td align="left"><code class="filename">tr1/cstdarg</code></td><td align="left"><code class="filename">tr1/cstdio</code></td><td align="left"><code class="filename">tr1/ctime</code></td></tr><tr><td align="left"><code class="filename">tr1/ccomplex</code></td><td align="left"><code class="filename">tr1/cinttypes</code></td><td align="left"><code class="filename">tr1/cstdbool</code></td><td align="left"><code class="filename">tr1/cstdlib</code></td><td align="left"><code class="filename">tr1/cwchar</code></td></tr><tr><td align="left"><code class="filename">tr1/cfenv</code></td><td align="left"><code class="filename">tr1/climits</code></td><td align="left"><code class="filename">tr1/cstdint</code></td><td align="left"><code class="filename">tr1/ctgmath</code></td><td align="left"><code class="filename">tr1/cwctype</code></td></tr></tbody></table></div></div><br class="table-break" /><p>
Also included are files for the C++ ABI interface:
</p><div class="table"><a id="id420398"></a><p class="title"><b>Table 3.7. C++ ABI Headers</b></p><div class="table-contents"><table summary="C++ ABI Headers" border="1"><colgroup><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">cxxabi.h</code></td><td align="left"><code class="filename">cxxabi_forced.h</code></td></tr></tbody></table></div></div><br class="table-break" /><p>
And a large variety of extensions.
</p><div class="table"><a id="id414207"></a><p class="title"><b>Table 3.8. Extension Headers</b></p><div class="table-contents"><table summary="Extension Headers" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">ext/algorithm</code></td><td align="left"><code class="filename">ext/debug_allocator.h</code></td><td align="left"><code class="filename">ext/mt_allocator.h</code></td><td align="left"><code class="filename">ext/pod_char_traits.h</code></td><td align="left"><code class="filename">ext/stdio_sync_filebuf.h</code></td></tr><tr><td align="left"><code class="filename">ext/array_allocator.h</code></td><td align="left"><code class="filename">ext/enc_filebuf.h</code></td><td align="left"><code class="filename">ext/new_allocator.h</code></td><td align="left"><code class="filename">ext/pool_allocator.h</code></td><td align="left"><code class="filename">ext/throw_allocator.h</code></td></tr><tr><td align="left"><code class="filename">ext/atomicity.h</code></td><td align="left"><code class="filename">ext/functional</code></td><td align="left"><code class="filename">ext/numeric</code></td><td align="left"><code class="filename">ext/rb_tree</code></td><td align="left"><code class="filename">ext/typelist.h</code></td></tr><tr><td align="left"><code class="filename">ext/bitmap_allocator.h</code></td><td align="left"><code class="filename">ext/iterator</code></td><td align="left"><code class="filename">ext/numeric_traits.h</code></td><td align="left"><code class="filename">ext/rope</code></td><td align="left"><code class="filename">ext/type_traits.h</code></td></tr><tr><td align="left"><code class="filename">ext/codecvt_specializations.h</code></td><td align="left"><code class="filename">ext/malloc_allocator.h</code></td><td align="left"><code class="filename">ext/pb_ds/assoc_container.h</code></td><td align="left"><code class="filename">ext/slist</code></td><td align="left"><code class="filename">ext/vstring.h</code></td></tr><tr><td align="left"><code class="filename">ext/concurrence.h</code></td><td align="left"><code class="filename">ext/memory</code></td><td align="left"><code class="filename">ext/pb_ds/priority_queue.h</code></td><td align="left"><code class="filename">ext/stdio_filebuf.h</code></td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p></p><div class="table"><a id="id458275"></a><p class="title"><b>Table 3.9. Extension Debug Headers</b></p><div class="table-contents"><table summary="Extension Debug Headers" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">debug/bitset</code></td><td align="left"><code class="filename">debug/list</code></td><td align="left"><code class="filename">debug/set</code></td><td align="left"><code class="filename">debug/unordered_map</code></td><td align="left"><code class="filename">debug/vector</code></td></tr><tr><td align="left"><code class="filename">debug/deque</code></td><td align="left"><code class="filename">debug/map</code></td><td align="left"><code class="filename">debug/string</code></td><td align="left"><code class="filename">debug/unordered_set</code></td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p></p><div class="table"><a id="id428288"></a><p class="title"><b>Table 3.10. Extension Parallel Headers</b></p><div class="table-contents"><table summary="Extension Parallel Headers" border="1"><colgroup><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">parallel/algorithm</code></td><td align="left"><code class="filename">parallel/numeric</code></td></tr></tbody></table></div></div><br class="table-break" /></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.headers.mixing"></a>Mixing Headers</h3></div></div></div><p> A few simple rules.
</p><p>First, mixing different dialects of the standard headers is not
possible. It's an all-or-nothing affair. Thus, code like
</p><pre class="programlisting">
#include &lt;array&gt;
#include &lt;functional&gt;
</pre><p>Implies C++0x mode. To use the entities in &lt;array&gt;, the C++0x
compilation mode must be used, which implies the C++0x functionality
(and deprecations) in &lt;functional&gt; will be present.
</p><p>Second, the other headers can be included with either dialect of
the standard headers, although features and types specific to C++0x
are still only enabled when in C++0x compilation mode. So, to use
rvalue references with <code class="code">__gnu_cxx::vstring</code>, or to use the
debug-mode versions of <code class="code">std::unordered_map</code>, one must use
the <code class="code">std=gnu++0x</code> compiler flag. (Or <code class="code">std=c++0x</code>, of course.)
</p><p>A special case of the second rule is the mixing of TR1 and C++0x
facilities. It is possible (although not especially prudent) to
include both the TR1 version and the C++0x version of header in the
same translation unit:
</p><pre class="programlisting">
#include &lt;tr1/type_traits&gt;
#include &lt;type_traits&gt;
</pre><p> Several parts of C++0x diverge quite substantially from TR1 predecessors.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.headers.cheaders"></a>The C Headers and <code class="code">namespace std</code></h3></div></div></div><p>
The standard specifies that if one includes the C-style header
(&lt;math.h&gt; in this case), the symbols will be available
in the global namespace and perhaps in
namespace <code class="code">std::</code> (but this is no longer a firm
requirement.) One the other hand, including the C++-style
header (&lt;cmath&gt;) guarantees that the entities will be
found in namespace std and perhaps in the global namespace.
</p><p>
Usage of C++-style headers is recommended, as then
C-linkage names can be disambiguated by explicit qualification, such
as by <code class="code">std::abort</code>. In addition, the C++-style headers can
use function overloading to provide a simpler interface to certain
families of C-functions. For instance in &lt;cmath&gt;, the
function <code class="code">std::sin</code> has overloads for all the builtin
floating-point types. This means that <code class="code">std::sin</code> can be
used uniformly, instead of a combination
of <code class="code">std::sinf</code>, <code class="code">std::sin</code>,
and <code class="code">std::sinl</code>.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.headers.pre"></a>Precompiled Headers</h3></div></div></div><p>There are three base header files that are provided. They can be
used to precompile the standard headers and extensions into binary
files that may the be used to speed compiles that use these headers.
</p><div class="itemizedlist"><ul type="disc"><li><p>stdc++.h</p><p>Includes all standard headers. Actual content varies depending on
language dialect.
</p></li><li><p>stdtr1c++.h</p><p>Includes all of &lt;stdc++.h&gt;, and adds all the TR1 headers.
</p></li><li><p>extc++.h</p><p>Includes all of &lt;stdtr1c++.h&gt;, and adds all the Extension headers.
</p></li></ul></div><p>How to construct a .gch file from one of these base header files.</p><p>First, find the include directory for the compiler. One way to do
this is:</p><pre class="programlisting">
g++ -v hello.cc
#include &lt;...&gt; search starts here:
/mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0
...
End of search list.
</pre><p>Then, create a precompiled header file with the same flags that
will be used to compile other projects.</p><pre class="programlisting">
g++ -Winvalid-pch -x c++-header -g -O2 -o ./stdc++.h.gch /mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0/x86_64-unknown-linux-gnu/bits/stdc++.h
</pre><p>The resulting file will be quite large: the current size is around
thirty megabytes. </p><p>How to use the resulting file.</p><pre class="programlisting">
g++ -I. -include stdc++.h -H -g -O2 hello.cc
</pre><p>Verification that the PCH file is being used is easy:</p><pre class="programlisting">
g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 hello.cc -o test.exe
! ./stdc++.h.gch
. /mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0/iostream
. /mnt/share/bld/H-x86-gcc.20071201include/c++/4.3.0/string
</pre><p>The exclamation point to the left of the <code class="code">stdc++.h.gch</code> listing means that the generated PCH file was used, and thus the </p><p></p><p> Detailed information about creating precompiled header files can be found in the GCC <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html" target="_top">documentation</a>.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="using.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt01ch03s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 3. Using </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Namespaces</td></tr></table></div></body></html>

61
libstdc++-v3/doc/html/manual/bk01pt01ch03s03.html Normal file
View File

@ -0,0 +1,61 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Namespaces</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="bk01pt01ch03s02.html" title="Headers" /><link rel="next" href="bk01pt01ch03s04.html" title="Macros" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Namespaces</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt01ch03s02.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt01ch03s04.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.namespaces"></a>Namespaces</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.namespaces.all"></a>Available Namespaces</h3></div></div></div><p> There are three main namespaces.
</p><div class="itemizedlist"><ul type="disc"><li><p>std</p><p>The ISO C++ standards specify that "all library entities are defined
within namespace std." This includes namepaces nested
within <code class="code">namespace std</code>, such as <code class="code">namespace
std::tr1</code>.
</p></li><li><p>abi</p><p>Specified by the C++ ABI. This ABI specifies a number of type and
function APIs supplemental to those required by the ISO C++ Standard,
but necessary for interoperability.
</p></li><li><p>__gnu_</p><p>Indicating one of several GNU extensions. Choices
include <code class="code">__gnu_cxx</code>, <code class="code">__gnu_debug</code>, <code class="code">__gnu_parallel</code>,
and <code class="code">__gnu_pbds</code>.
</p></li></ul></div><p> A complete list of implementation namespaces (including namespace contents) is available in the generated source <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/namespaces.html" target="_top">documentation</a>.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.namespaces.std"></a>namespace std</h3></div></div></div><p>
One standard requirement is that the library components are defined
in <code class="code">namespace std::</code>. Thus, in order to use these types or
functions, one must do one of two things:
</p><div class="itemizedlist"><ul type="disc"><li><p>put a kind of <span class="emphasis"><em>using-declaration</em></span> in your source
(either <code class="code">using namespace std;</code> or i.e. <code class="code">using
std::string;</code>) This approach works well for individual source files, but
should not be used in a global context, like header files.
</p></li><li><p>use a <span class="emphasis"><em>fully
qualified name</em></span>for each library symbol
(i.e. <code class="code">std::string</code>, <code class="code">std::cout</code>) Always can be
used, and usually enhanced, by strategic use of typedefs. (In the
cases where the qualified verbiage becomes unwieldy.)
</p></li></ul></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.namespaces.comp"></a>Using Namespace Composition</h3></div></div></div><p>
Best practice in programming suggests sequestering new data or
functionality in a sanely-named, unique namespace whenever
possible. This is considered an advantage over dumping everything in
the global namespace, as then name look-up can be explicitly enabled or
disabled as above, symbols are consistently mangled without repetitive
naming prefixes or macros, etc.
</p><p>For instance, consider a project that defines most of its classes in <code class="code">namespace gtk</code>. It is possible to
adapt <code class="code">namespace gtk</code> to <code class="code">namespace std</code> by using a C++-feature called
<span class="emphasis"><em>namespace composition</em></span>. This is what happens if
a <span class="emphasis"><em>using</em></span>-declaration is put into a
namespace-definition: the imported symbol(s) gets imported into the
currently active namespace(s). For example:
</p><pre class="programlisting">
namespace gtk
{
using std::string;
using std::tr1::array;
class Window { ... };
}
</pre><p>
In this example, <code class="code">std::string</code> gets imported into
<code class="code">namespace gtk</code>. The result is that use of
<code class="code">std::string</code> inside namespace gtk can just use <code class="code">string</code>, without the explicit qualification.
As an added bonus,
<code class="code">std::string</code> does not get imported into
the global namespace. Additionally, a more elaborate arrangement can be made for backwards compatibility and portability, whereby the
<code class="code">using</code>-declarations can wrapped in macros that
are set based on autoconf-tests to either "" or i.e. <code class="code">using
std::string;</code> (depending on whether the system has
libstdc++ in <code class="code">std::</code> or not). (ideas from
<code class="email">&lt;<a class="email" href="mailto:llewelly@dbritsch.dsl.xmission.com">llewelly@dbritsch.dsl.xmission.com</a>&gt;</code>, Karl Nelson <code class="email">&lt;<a class="email" href="mailto:kenelson@ece.ucdavis.edu">kenelson@ece.ucdavis.edu</a>&gt;</code>)
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt01ch03s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt01ch03s04.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Headers </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Macros</td></tr></table></div></body></html>

70
libstdc++-v3/doc/html/manual/bk01pt01ch03s04.html Normal file
View File

@ -0,0 +1,70 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Macros</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="bk01pt01ch03s03.html" title="Namespaces" /><link rel="next" href="bk01pt01ch03s05.html" title="Concurrency" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Macros</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt01ch03s03.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt01ch03s05.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.macros"></a>Macros</h2></div></div></div><p>All pre-processor switches and configurations are all gathered
in the file <code class="code">c++config.h</code>, which is generated during
the libstdc++ configuration and build process, and included by
files part of the public libstdc++ API. Most of these macros
should not be used by consumers of libstdc++, and are reserved
for internal implementation use. <span class="emphasis"><em>These macros cannot be
redefined</em></span>. However, a select handful of these macro
control libstdc++ extensions and extra features, or provide
versioning information for the API, and are able to be used.
</p><p>All library macros begin with <code class="code">_GLIBCXX_</code> (except for
versions 3.1.x to 3.3.x, which use <code class="code">_GLIBCPP_</code>).
</p><p>Below is the macro which users may check for library version
information. </p><div class="variablelist"><dl><dt><span class="term"><code class="code">__GLIBCXX__</code></span></dt><dd><p>The current version of
libstdc++ in compressed ISO date format, form of an unsigned
long. For details on the value of this particular macro for a
particular release, please consult this <a class="ulink" href="abi.html" target="_top">
document</a>.
</p></dd></dl></div><p>Below are the macros which users may change with #define/#undef or
with -D/-U compiler flags. The default state of the symbol is
listed.</p><p>“<span class="quote">Configurable</span>” (or “<span class="quote">Not configurable</span>”) means
that the symbol is initially chosen (or not) based on
--enable/--disable options at library build and configure time
(documented <a class="link" href="bk01pt01ch02.html#manual.intro.setup.configure" title="Configure">here</a>), with the
various --enable/--disable choices being translated to
#define/#undef).
</p><p> <acronym class="acronym">ABI</acronym> means that changing from the default value may
mean changing the <acronym class="acronym">ABI</acronym> of compiled code. In other words, these
choices control code which has already been compiled (i.e., in a
binary such as libstdc++.a/.so). If you explicitly #define or
#undef these macros, the <span class="emphasis"><em>headers</em></span> may see different code
paths, but the <span class="emphasis"><em>libraries</em></span> which you link against will not.
Experimenting with different values with the expectation of
consistent linkage requires changing the config headers before
building/installing the library.
</p><div class="variablelist"><dl><dt><span class="term"><code class="code">_GLIBCXX_DEPRECATED</code></span></dt><dd><p>
Defined by default. Not configurable. ABI-changing. Turning this off
removes older ARM-style iostreams code, and other anachronisms
from the API. This macro is dependent on the version of the
standard being tracked, and as a result may give different results for
<code class="code">-std=c++98</code> and <code class="code">-std=c++0x</code>. This may
be useful in updating old C++ code which no longer meet the
requirements of the language, or for checking current code
against new language standards.
</p></dd><dt><span class="term"><code class="code">_GLIBCXX_FORCE_NEW</code></span></dt><dd><p>
Undefined by default. When defined, memory allocation and
allocators controlled by libstdc++ call operator new/delete
without caching and pooling. Configurable via
<code class="code">--enable-libstdcxx-allocator</code>. ABI-changing.
</p></dd><dt><span class="term"><code class="code">_GLIBCXX_CONCEPT_CHECKS</code></span></dt><dd><p>
Undefined by default. Configurable via
<code class="code">--enable-concept-checks</code>. When defined, performs
compile-time checking on certain template instantiations to
detect violations of the requirements of the standard. This
is described in more detail <a class="ulink" href="../19_diagnostics/howto.html#3" target="_top">here</a>.
</p></dd><dt><span class="term"><code class="code">_GLIBCXX_DEBUG</code></span></dt><dd><p>
Undefined by default. When defined, compiles
user code using the <a class="ulink" href="../ext/debug.html#safe" target="_top">libstdc++ debug
mode</a>.
</p></dd><dt><span class="term"><code class="code">_GLIBCXX_DEBUG_PEDANTIC</code></span></dt><dd><p>
Undefined by default. When defined while
compiling with the <a class="ulink" href="../ext/debug.html#safe" target="_top">libstdc++ debug
mode</a>, makes the debug mode extremely picky by making the use
of libstdc++ extensions and libstdc++-specific behavior into
errors.
</p></dd><dt><span class="term"><code class="code">_GLIBCXX_PARALLEL</code></span></dt><dd><p>Undefined by default. When defined, compiles
user code using the <a class="ulink" href="../ext/parallel_mode.html" target="_top">libstdc++ parallel
mode</a>.
</p></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt01ch03s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt01ch03s05.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Namespaces </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Concurrency</td></tr></table></div></body></html>

219
libstdc++-v3/doc/html/manual/bk01pt01ch03s05.html Normal file
View File

@ -0,0 +1,219 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Concurrency</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="bk01pt01ch03s04.html" title="Macros" /><link rel="next" href="bk01pt01ch03s06.html" title="Exception Safety" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Concurrency</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt01ch03s04.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt01ch03s06.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.concurrency"></a>Concurrency</h2></div></div></div><p>This section discusses issues surrounding the proper compilation
of multithreaded applications which use the Standard C++
library. This information is GCC-specific since the C++
standard does not address matters of multithreaded applications.
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.concurrency.prereq"></a>Prerequisites</h3></div></div></div><p>All normal disclaimers aside, multithreaded C++ application are
only supported when libstdc++ and all user code was built with
compilers which report (via <code class="code"> gcc/g++ -v </code>) the same thread
model and that model is not <span class="emphasis"><em>single</em></span>. As long as your
final application is actually single-threaded, then it should be
safe to mix user code built with a thread model of
<span class="emphasis"><em>single</em></span> with a libstdc++ and other C++ libraries built
with another thread model useful on the platform. Other mixes
may or may not work but are not considered supported. (Thus, if
you distribute a shared C++ library in binary form only, it may
be best to compile it with a GCC configured with
--enable-threads for maximal interchangeability and usefulness
with a user population that may have built GCC with either
--enable-threads or --disable-threads.)
</p><p>When you link a multithreaded application, you will probably
need to add a library or flag to g++. This is a very
non-standardized area of GCC across ports. Some ports support a
special flag (the spelling isn't even standardized yet) to add
all required macros to a compilation (if any such flags are
required then you must provide the flag for all compilations not
just linking) and link-library additions and/or replacements at
link time. The documentation is weak. Here is a quick summary
to display how ad hoc this is: On Solaris, both -pthreads and
-threads (with subtly different meanings) are honored. On OSF,
-pthread and -threads (with subtly different meanings) are
honored. On Linux/i386, -pthread is honored. On FreeBSD,
-pthread is honored. Some other ports use other switches.
AFAIK, none of this is properly documented anywhere other than
in ``gcc -dumpspecs'' (look at lib and cpp entries).
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.concurrency.thread_safety"></a>Thread Safety</h3></div></div></div><p>
We currently use the <a class="ulink" href="http://www.sgi.com/tech/stl/thread_safety.html" target="_top">SGI STL</a> definition of thread safety.
</p><p>The library strives to be thread-safe when all of the following
conditions are met:
</p><div class="itemizedlist"><ul type="disc"><li><p>The system's libc is itself thread-safe,
</p></li><li><p>
The compiler in use reports a thread model other than
'single'. This can be tested via output from <code class="code">gcc
-v</code>. Multi-thread capable versions of gcc output
something like this:
</p><pre class="programlisting">
%gcc -v
Using built-in specs.
...
Thread model: posix
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
</pre><p>Look for "Thread model" lines that aren't equal to "single."</p></li><li><p>
Requisite command-line flags are used for atomic operations
and threading. Examples of this include <code class="code">-pthread</code>
and <code class="code">-march=native</code>, although specifics vary
depending on the host environment. See <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html" target="_top">Machine
Dependent Options</a>.
</p></li><li><p>
An implementation of atomicity.h functions
exists for the architecture in question. See the internals documentation for more <a class="ulink" href="../ext/concurrence.html" target="_top">details</a>.
</p></li></ul></div><p>The user-code must guard against concurrent method calls which may
access any particular library object's state. Typically, the
application programmer may infer what object locks must be held
based on the objects referenced in a method call. Without getting
into great detail, here is an example which requires user-level
locks:
</p><pre class="programlisting">
library_class_a shared_object_a;
thread_main () {
library_class_b *object_b = new library_class_b;
shared_object_a.add_b (object_b); // must hold lock for shared_object_a
shared_object_a.mutate (); // must hold lock for shared_object_a
}
// Multiple copies of thread_main() are started in independent threads.</pre><p>Under the assumption that object_a and object_b are never exposed to
another thread, here is an example that should not require any
user-level locks:
</p><pre class="programlisting">
thread_main () {
library_class_a object_a;
library_class_b *object_b = new library_class_b;
object_a.add_b (object_b);
object_a.mutate ();
} </pre><p>All library objects are safe to use in a multithreaded program as
long as each thread carefully locks out access by any other
thread while it uses any object visible to another thread, i.e.,
treat library objects like any other shared resource. In general,
this requirement includes both read and write access to objects;
unless otherwise documented as safe, do not assume that two threads
may access a shared standard library object at the same time.
</p><p>See chapters <a class="ulink" href="../17_intro/howto.html#3" target="_top">17</a> (library
introduction), <a class="ulink" href="../23_containers/howto.html#3" target="_top">23</a>
(containers), and <a class="ulink" href="../27_io/howto.html#9" target="_top">27</a> (I/O) for
more information.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.concurrency.atomics"></a>Atomics</h3></div></div></div><p>
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.concurrency.io"></a>IO</h3></div></div></div><p>I'll assume that you have already read the
<a class="ulink" href="../17_intro/howto.html#3" target="_top">general notes on library threads</a>,
and the
<a class="ulink" href="../23_containers/howto.html#3" target="_top">notes on threaded container
access</a> (you might not think of an I/O stream as a container, but
the points made there also hold here). If you have not read them,
please do so first.
</p><p>This gets a bit tricky. Please read carefully, and bear with me.
</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="concurrency.io.structure"></a>Structure</h4></div></div></div><p>A wrapper
type called <code class="code">__basic_file</code> provides our abstraction layer
for the <code class="code">std::filebuf</code> classes. Nearly all decisions dealing
with actual input and output must be made in <code class="code">__basic_file</code>.
</p><p>A generic locking mechanism is somewhat in place at the filebuf layer,
but is not used in the current code. Providing locking at any higher
level is akin to providing locking within containers, and is not done
for the same reasons (see the links above).
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="concurrency.io.defaults"></a>Defaults</h4></div></div></div><p>The __basic_file type is simply a collection of small wrappers around
the C stdio layer (again, see the link under Structure). We do no
locking ourselves, but simply pass through to calls to <code class="code">fopen</code>,
<code class="code">fwrite</code>, and so forth.
</p><p>So, for 3.0, the question of "is multithreading safe for I/O"
must be answered with, "is your platform's C library threadsafe
for I/O?" Some are by default, some are not; many offer multiple
implementations of the C library with varying tradeoffs of threadsafety
and efficiency. You, the programmer, are always required to take care
with multiple threads.
</p><p>(As an example, the POSIX standard requires that C stdio FILE*
operations are atomic. POSIX-conforming C libraries (e.g, on Solaris
and GNU/Linux) have an internal mutex to serialize operations on
FILE*s. However, you still need to not do stupid things like calling
<code class="code">fclose(fs)</code> in one thread followed by an access of
<code class="code">fs</code> in another.)
</p><p>So, if your platform's C library is threadsafe, then your
<code class="code">fstream</code> I/O operations will be threadsafe at the lowest
level. For higher-level operations, such as manipulating the data
contained in the stream formatting classes (e.g., setting up callbacks
inside an <code class="code">std::ofstream</code>), you need to guard such accesses
like any other critical shared resource.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="concurrency.io.future"></a>Future</h4></div></div></div><p> A
second choice may be available for I/O implementations: libio. This is
disabled by default, and in fact will not currently work due to other
issues. It will be revisited, however.
</p><p>The libio code is a subset of the guts of the GNU libc (glibc) I/O
implementation. When libio is in use, the <code class="code">__basic_file</code>
type is basically derived from FILE. (The real situation is more
complex than that... it's derived from an internal type used to
implement FILE. See libio/libioP.h to see scary things done with
vtbls.) The result is that there is no "layer" of C stdio
to go through; the filebuf makes calls directly into the same
functions used to implement <code class="code">fread</code>, <code class="code">fwrite</code>,
and so forth, using internal data structures. (And when I say
"makes calls directly," I mean the function is literally
replaced by a jump into an internal function. Fast but frightening.
*grin*)
</p><p>Also, the libio internal locks are used. This requires pulling in
large chunks of glibc, such as a pthreads implementation, and is one
of the issues preventing widespread use of libio as the libstdc++
cstdio implementation.
</p><p>But we plan to make this work, at least as an option if not a future
default. Platforms running a copy of glibc with a recent-enough
version will see calls from libstdc++ directly into the glibc already
installed. For other platforms, a copy of the libio subsection will
be built and included in libstdc++.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="concurrency.io.alt"></a>Alternatives</h4></div></div></div><p>Don't forget that other cstdio implementations are possible. You could
easily write one to perform your own forms of locking, to solve your
"interesting" problems.
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.concurrency.containers"></a>Containers</h3></div></div></div><p>This section discusses issues surrounding the design of
multithreaded applications which use Standard C++ containers.
All information in this section is current as of the gcc 3.0
release and all later point releases. Although earlier gcc
releases had a different approach to threading configuration and
proper compilation, the basic code design rules presented here
were similar. For information on all other aspects of
multithreading as it relates to libstdc++, including details on
the proper compilation of threaded code (and compatibility between
threaded and non-threaded code), see Chapter 17.
</p><p>Two excellent pages to read when working with the Standard C++
containers and threads are
<a class="ulink" href="http://www.sgi.com/tech/stl/thread_safety.html" target="_top">SGI's
http://www.sgi.com/tech/stl/thread_safety.html</a> and
<a class="ulink" href="http://www.sgi.com/tech/stl/Allocators.html" target="_top">SGI's
http://www.sgi.com/tech/stl/Allocators.html</a>.
</p><p><span class="emphasis"><em>However, please ignore all discussions about the user-level
configuration of the lock implementation inside the STL
container-memory allocator on those pages. For the sake of this
discussion, libstdc++ configures the SGI STL implementation,
not you. This is quite different from how gcc pre-3.0 worked.
In particular, past advice was for people using g++ to
explicitly define _PTHREADS or other macros or port-specific
compilation options on the command line to get a thread-safe
STL. This is no longer required for any port and should no
longer be done unless you really know what you are doing and
assume all responsibility.</em></span>
</p><p>Since the container implementation of libstdc++ uses the SGI
code, we use the same definition of thread safety as SGI when
discussing design. A key point that beginners may miss is the
fourth major paragraph of the first page mentioned above
("For most clients,"...), which points out that
locking must nearly always be done outside the container, by
client code (that'd be you, not us). There is a notable
exceptions to this rule. Allocators called while a container or
element is constructed uses an internal lock obtained and
released solely within libstdc++ code (in fact, this is the
reason STL requires any knowledge of the thread configuration).
</p><p>For implementing a container which does its own locking, it is
trivial to provide a wrapper class which obtains the lock (as
SGI suggests), performs the container operation, and then
releases the lock. This could be templatized <span class="emphasis"><em>to a certain
extent</em></span>, on the underlying container and/or a locking
mechanism. Trying to provide a catch-all general template
solution would probably be more trouble than it's worth.
</p><p>The STL implementation is currently configured to use the
high-speed caching memory allocator. Some people like to
test and/or normally run threaded programs with a different
default. For all details about how to globally override this
at application run-time see <a class="ulink" href="../ext/howto.html#3" target="_top">here</a>.
</p><p>There is a better way (not standardized yet): It is possible to
force the malloc-based allocator on a per-case-basis for some
application code. The library team generally believes that this
is a better way to tune an application for high-speed using this
implementation of the STL. There is
<a class="ulink" href="../ext/howto.html#3" target="_top">more information on allocators here</a>.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt01ch03s04.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt01ch03s06.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Macros </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Exception Safety</td></tr></table></div></body></html>

3
libstdc++-v3/doc/html/manual/bk01pt01ch03s06.html Normal file
View File

@ -0,0 +1,3 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Exception Safety</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="bk01pt01ch03s05.html" title="Concurrency" /><link rel="next" href="debug.html" title="Debugging Support" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Exception Safety</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt01ch03s05.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="debug.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.exception_safety"></a>Exception Safety</h2></div></div></div><p></p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt01ch03s05.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="debug.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Concurrency </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Debugging Support</td></tr></table></div></body></html>

40
libstdc++-v3/doc/html/manual/bk01pt02ch04.html Normal file
View File

@ -0,0 +1,40 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 4. Types</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="support.html" title="Part II. Support" /><link rel="prev" href="bk01pt02pr01.html" title="" /><link rel="next" href="bk01pt02ch04s02.html" title="Numeric Properties" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 4. Types</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt02pr01.html">Prev</a> </td><th width="60%" align="center">Part II. Support</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt02ch04s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.support.types"></a>Chapter 4. Types</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt02ch04.html#manual.support.types.fundamental">Fundamental Types</a></span></dt><dt><span class="sect1"><a href="bk01pt02ch04s02.html">Numeric Properties</a></span></dt><dt><span class="sect1"><a href="bk01pt02ch04s03.html">NULL</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.support.types.fundamental"></a>Fundamental Types</h2></div></div></div><p>
C++ has the following builtin types:
</p><div class="itemizedlist"><ul type="disc"><li><p>
char
</p></li><li><p>
signed char
</p></li><li><p>
unsigned char
</p></li><li><p>
signed short
</p></li><li><p>
signed int
</p></li><li><p>
signed long
</p></li><li><p>
unsigned short
</p></li><li><p>
unsigned int
</p></li><li><p>
unsigned long
</p></li><li><p>
bool
</p></li><li><p>
wchar_t
</p></li><li><p>
float
</p></li><li><p>
double
</p></li><li><p>
long double
</p></li></ul></div><p>
These fundamental types are always available, without having to
include a header file. These types are exactly the same in
either C++ or in C.
</p><p>
Specializing parts of the library on these types is prohibited:
instead, use a POD.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt02pr01.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="support.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt02ch04s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Numeric Properties</td></tr></table></div></body></html>

49
libstdc++-v3/doc/html/manual/bk01pt02ch04s02.html Normal file
View File

@ -0,0 +1,49 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Numeric Properties</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt02ch04.html" title="Chapter 4. Types" /><link rel="prev" href="bk01pt02ch04.html" title="Chapter 4. Types" /><link rel="next" href="bk01pt02ch04s03.html" title="NULL" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Numeric Properties</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt02ch04.html">Prev</a> </td><th width="60%" align="center">Chapter 4. Types</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt02ch04s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.support.types.numeric_limits"></a>Numeric Properties</h2></div></div></div><p>
The header <code class="filename">limits</code> defines
traits classes to give access to various implementation
defined-aspects of the fundamental types. The traits classes --
fourteen in total -- are all specializations of the template class
<code class="classname">numeric_limits</code>, documented <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/structstd_1_1numeric__limits.html" target="_top">here</a>
and defined as follows:
</p><pre class="programlisting">
template&lt;typename T&gt;
struct class
{
static const bool is_specialized;
static T max() throw();
static T min() throw();
static const int digits;
static const int digits10;
static const bool is_signed;
static const bool is_integer;
static const bool is_exact;
static const int radix;
static T epsilon() throw();
static T round_error() throw();
static const int min_exponent;
static const int min_exponent10;
static const int max_exponent;
static const int max_exponent10;
static const bool has_infinity;
static const bool has_quiet_NaN;
static const bool has_signaling_NaN;
static const float_denorm_style has_denorm;
static const bool has_denorm_loss;
static T infinity() throw();
static T quiet_NaN() throw();
static T denorm_min() throw();
static const bool is_iec559;
static const bool is_bounded;
static const bool is_modulo;
static const bool traps;
static const bool tinyness_before;
static const float_round_style round_style;
};
</pre></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt02ch04.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt02ch04.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt02ch04s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 4. Types </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> NULL</td></tr></table></div></body></html>

29
libstdc++-v3/doc/html/manual/bk01pt02ch04s03.html Normal file
View File

@ -0,0 +1,29 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>NULL</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt02ch04.html" title="Chapter 4. Types" /><link rel="prev" href="bk01pt02ch04s02.html" title="Numeric Properties" /><link rel="next" href="bk01pt02ch05.html" title="Chapter 5. Dynamic Memory" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">NULL</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt02ch04s02.html">Prev</a> </td><th width="60%" align="center">Chapter 4. Types</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt02ch05.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.support.types.null"></a>NULL</h2></div></div></div><p>
The only change that might affect people is the type of
<code class="constant">NULL</code>: while it is required to be a macro,
the definition of that macro is <span class="emphasis"><em>not</em></span> allowed
to be <code class="constant">(void*)0</code>, which is often used in C.
</p><p>
For <span class="command"><strong>g++</strong></span>, <code class="constant">NULL</code> is
</p><pre class="programlisting">#define</pre><p>'d to be
<code class="constant">__null</code>, a magic keyword extension of
<span class="command"><strong>g++</strong></span>.
</p><p>
The biggest problem of #defining <code class="constant">NULL</code> to be
something like “<span class="quote">0L</span>” is that the compiler will view
that as a long integer before it views it as a pointer, so
overloading won't do what you expect. (This is why
<span class="command"><strong>g++</strong></span> has a magic extension, so that
<code class="constant">NULL</code> is always a pointer.)
</p><p>In his book <a class="ulink" href="http://www.awprofessional.com/titles/0-201-92488-9/" target="_top"><span class="emphasis"><em>Effective
C++</em></span></a>, Scott Meyers points out that the best way
to solve this problem is to not overload on pointer-vs-integer
types to begin with. He also offers a way to make your own magic
<code class="constant">NULL</code> that will match pointers before it
matches integers.
</p><p>See
<a class="ulink" href="http://www.awprofessional.com/titles/0-201-31015-5/" target="_top">the
Effective C++ CD example</a>
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt02ch04s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt02ch04.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt02ch05.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Numeric Properties </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 5. Dynamic Memory</td></tr></table></div></body></html>

66
libstdc++-v3/doc/html/manual/bk01pt02ch05.html Normal file
View File

@ -0,0 +1,66 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 5. Dynamic Memory</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="support.html" title="Part II. Support" /><link rel="prev" href="bk01pt02ch04s03.html" title="NULL" /><link rel="next" href="bk01pt02ch06.html" title="Chapter 6. Termination" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 5. Dynamic Memory</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt02ch04s03.html">Prev</a> </td><th width="60%" align="center">Part II. Support</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt02ch06.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.support.memory"></a>Chapter 5. Dynamic Memory</h2></div></div></div><p>
There are six flavors each of <code class="function">new</code> and
<code class="function">delete</code>, so make certain that you're using the right
ones. Here are quickie descriptions of <code class="function">new</code>:
</p><div class="itemizedlist"><ul type="disc"><li><p>
single object form, throwing a
<code class="classname">bad_alloc</code> on errors; this is what most
people are used to using
</p></li><li><p>
Single object "nothrow" form, returning NULL on errors
</p></li><li><p>
Array <code class="function">new</code>, throwing
<code class="classname">bad_alloc</code> on errors
</p></li><li><p>
Array nothrow <code class="function">new</code>, returning
<code class="constant">NULL</code> on errors
</p></li><li><p>
Placement <code class="function">new</code>, which does nothing (like
it's supposed to)
</p></li><li><p>
Placement array <code class="function">new</code>, which also does
nothing
</p></li></ul></div><p>
They are distinguished by the parameters that you pass to them, like
any other overloaded function. The six flavors of <code class="function">delete</code>
are distinguished the same way, but none of them are allowed to throw
an exception under any circumstances anyhow. (They match up for
completeness' sake.)
</p><p>
Remember that it is perfectly okay to call <code class="function">delete</code> on a
NULL pointer! Nothing happens, by definition. That is not the
same thing as deleting a pointer twice.
</p><p>
By default, if one of the “<span class="quote">throwing <code class="function">new</code>s</span>” can't
allocate the memory requested, it tosses an instance of a
<code class="classname">bad_alloc</code> exception (or, technically, some class derived
from it). You can change this by writing your own function (called a
new-handler) and then registering it with <code class="function">set_new_handler()</code>:
</p><pre class="programlisting">
typedef void (*PFV)(void);
static char* safety;
static PFV old_handler;
void my_new_handler ()
{
delete[] safety;
popup_window ("Dude, you are running low on heap memory. You
should, like, close some windows, or something.
The next time you run out, we're gonna burn!");
set_new_handler (old_handler);
return;
}
int main ()
{
safety = new char[500000];
old_handler = set_new_handler (&amp;my_new_handler);
...
}
</pre><p>
<code class="classname">bad_alloc</code> is derived from the base <code class="classname">exception</code>
class defined in Chapter 19.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt02ch04s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="support.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt02ch06.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">NULL </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 6. Termination</td></tr></table></div></body></html>

45
libstdc++-v3/doc/html/manual/bk01pt02ch06.html Normal file
View File

@ -0,0 +1,45 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 6. Termination</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="support.html" title="Part II. Support" /><link rel="prev" href="bk01pt02ch05.html" title="Chapter 5. Dynamic Memory" /><link rel="next" href="bk01pt02ch06s02.html" title="Verbose Terminate Handler" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 6. Termination</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt02ch05.html">Prev</a> </td><th width="60%" align="center">Part II. Support</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt02ch06s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.support.termination"></a>Chapter 6. Termination</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt02ch06.html#support.termination.handlers">Termination Handlers</a></span></dt><dt><span class="sect1"><a href="bk01pt02ch06s02.html">Verbose Terminate Handler</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="support.termination.handlers"></a>Termination Handlers</h2></div></div></div><p>
Not many changes here to <code class="filename">cstdlib</code>. You should note that the
<code class="function">abort()</code> function does not call the
destructors of automatic nor static objects, so if you're
depending on those to do cleanup, it isn't going to happen.
(The functions registered with <code class="function">atexit()</code>
don't get called either, so you can forget about that
possibility, too.)
</p><p>
The good old <code class="function">exit()</code> function can be a bit
funky, too, until you look closer. Basically, three points to
remember are:
</p><div class="orderedlist"><ol type="1"><li><p>
Static objects are destroyed in reverse order of their creation.
</p></li><li><p>
Functions registered with <code class="function">atexit()</code> are called in
reverse order of registration, once per registration call.
(This isn't actually new.)
</p></li><li><p>
The previous two actions are “<span class="quote">interleaved,</span>” that is,
given this pseudocode:
</p><pre class="programlisting">
extern "C or C++" void f1 (void);
extern "C or C++" void f2 (void);
static Thing obj1;
atexit(f1);
static Thing obj2;
atexit(f2);
</pre><p>
then at a call of <code class="function">exit()</code>,
<code class="varname">f2</code> will be called, then
<code class="varname">obj2</code> will be destroyed, then
<code class="varname">f1</code> will be called, and finally
<code class="varname">obj1</code> will be destroyed. If
<code class="varname">f1</code> or <code class="varname">f2</code> allow an
exception to propagate out of them, Bad Things happen.
</p></li></ol></div><p>
Note also that <code class="function">atexit()</code> is only required to store 32
functions, and the compiler/library might already be using some of
those slots. If you think you may run out, we recommend using
the <code class="function">xatexit</code>/<code class="function">xexit</code> combination from <code class="literal">libiberty</code>, which has no such limit.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt02ch05.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="support.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt02ch06s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 5. Dynamic Memory </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Verbose Terminate Handler</td></tr></table></div></body></html>

76
libstdc++-v3/doc/html/manual/bk01pt02ch06s02.html Normal file
View File

@ -0,0 +1,76 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Verbose Terminate Handler</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt02ch06.html" title="Chapter 6. Termination" /><link rel="prev" href="bk01pt02ch06.html" title="Chapter 6. Termination" /><link rel="next" href="diagnostics.html" title="Part III. Diagnostics" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Verbose Terminate Handler</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt02ch06.html">Prev</a> </td><th width="60%" align="center">Chapter 6. Termination</th><td width="20%" align="right"> <a accesskey="n" href="diagnostics.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="support.termination.verbose"></a>Verbose Terminate Handler</h2></div></div></div><p>
If you are having difficulty with uncaught exceptions and want a
little bit of help debugging the causes of the core dumps, you can
make use of a GNU extension, the verbose terminate handler.
</p><pre class="programlisting">
#include &lt;exception&gt;
int main()
{
std::set_terminate(__gnu_cxx::__verbose_terminate_handler);
...
throw <em class="replaceable"><code>anything</code></em>;
}
</pre><p>
The <code class="function">__verbose_terminate_handler</code> function
obtains the name of the current exception, attempts to demangle
it, and prints it to stderr. If the exception is derived from
<code class="classname">exception</code> then the output from
<code class="function">what()</code> will be included.
</p><p>
Any replacement termination function is required to kill the
program without returning; this one calls abort.
</p><p>
For example:
</p><pre class="programlisting">
#include &lt;exception&gt;
#include &lt;stdexcept&gt;
struct argument_error : public std::runtime_error
{
argument_error(const std::string&amp; s): std::runtime_error(s) { }
};
int main(int argc)
{
std::set_terminate(__gnu_cxx::__verbose_terminate_handler);
if (argc &gt; 5)
throw argument_error(“<span class="quote">argc is greater than 5!</span>”);
else
throw argc;
}
</pre><p>
With the verbose terminate handler active, this gives:
</p><pre class="screen">
<code class="computeroutput">
% ./a.out
terminate called after throwing a `int'
Aborted
% ./a.out f f f f f f f f f f f
terminate called after throwing an instance of `argument_error'
what(): argc is greater than 5!
Aborted
</code>
</pre><p>
The 'Aborted' line comes from the call to
<code class="function">abort()</code>, of course.
</p><p>
This is the default termination handler; nothing need be done to
use it. To go back to the previous “<span class="quote">silent death</span>”
method, simply include <code class="filename">exception</code> and
<code class="filename">cstdlib</code>, and call
</p><pre class="programlisting">
std::set_terminate(std::abort);
</pre><p>
After this, all calls to <code class="function">terminate</code> will use
<code class="function">abort</code> as the terminate handler.
</p><p>
Note: the verbose terminate handler will attempt to write to
stderr. If your application closes stderr or redirects it to an
inappropriate location,
<code class="function">__verbose_terminate_handler</code> will behave in
an unspecified manner.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt02ch06.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt02ch06.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="diagnostics.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 6. Termination </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part III. Diagnostics</td></tr></table></div></body></html>

11
libstdc++-v3/doc/html/manual/bk01pt02pr01.html Normal file
View File

@ -0,0 +1,11 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="support.html" title="Part II. Support" /><link rel="prev" href="support.html" title="Part II. Support" /><link rel="next" href="bk01pt02ch04.html" title="Chapter 4. Types" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="support.html">Prev</a> </td><th width="60%" align="center">Part II. Support</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt02ch04.html">Next</a></td></tr></table><hr /></div><div class="preface" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="id394397"></a></h2></div></div></div><p>
This part deals with the functions called and objects created
automatically during the course of a program's existence.
</p><p>
While we can't reproduce the contents of the Standard here (you
need to get your own copy from your nation's member body; see our
homepage for help), we can mention a couple of changes in what
kind of support a C++ program gets from the Standard Library.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="support.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="support.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt02ch04.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part II. Support </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 4. Types</td></tr></table></div></body></html>

16
libstdc++-v3/doc/html/manual/bk01pt03ch07.html Normal file
View File

@ -0,0 +1,16 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 7. Exceptions</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="diagnostics.html" title="Part III. Diagnostics" /><link rel="prev" href="diagnostics.html" title="Part III. Diagnostics" /><link rel="next" href="bk01pt03ch07s02.html" title="Adding Data to Exceptions" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 7. Exceptions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="diagnostics.html">Prev</a> </td><th width="60%" align="center">Part III. Diagnostics</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt03ch07s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.diagnostics.exceptions"></a>Chapter 7. Exceptions</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt03ch07.html#manual.diagnostics.exceptions.hierarchy">Exception Classes</a></span></dt><dt><span class="sect1"><a href="bk01pt03ch07s02.html">Adding Data to Exceptions</a></span></dt><dt><span class="sect1"><a href="bk01pt03ch07s03.html">Cancellation</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.diagnostics.exceptions.hierarchy"></a>Exception Classes</h2></div></div></div><p>
All exception objects are defined in one of the standard header
files: <code class="filename">exception</code>,
<code class="filename">stdexcept</code>, <code class="filename">new</code>, and
<code class="filename">typeinfo</code>.
</p><p>
The base exception object is <code class="classname">exception</code>,
located in <code class="filename">exception</code>. This object has no
<code class="classname">string</code> member.
</p><p>
Derived from this are several classes that may have a
<code class="classname">string</code> member: a full heirarchy can be
found in the <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00233.html" target="_top">source documentation</a>.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="diagnostics.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="diagnostics.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt03ch07s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part III. Diagnostics </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Adding Data to Exceptions</td></tr></table></div></body></html>

20
libstdc++-v3/doc/html/manual/bk01pt03ch07s02.html Normal file
View File

@ -0,0 +1,20 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Adding Data to Exceptions</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt03ch07.html" title="Chapter 7. Exceptions" /><link rel="prev" href="bk01pt03ch07.html" title="Chapter 7. Exceptions" /><link rel="next" href="bk01pt03ch07s03.html" title="Cancellation" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Adding Data to Exceptions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt03ch07.html">Prev</a> </td><th width="60%" align="center">Chapter 7. Exceptions</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt03ch07s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.diagnostics.exceptions.data"></a>Adding Data to Exceptions</h2></div></div></div><p>
The standard exception classes carry with them a single string as
data (usually describing what went wrong or where the 'throw' took
place). It's good to remember that you can add your own data to
these exceptions when extending the hierarchy:
</p><pre class="programlisting">
struct My_Exception : public std::runtime_error
{
public:
My_Exception (const string&amp; whatarg)
: std::runtime_error(whatarg), e(errno), id(GetDataBaseID()) { }
int errno_at_time_of_throw() const { return e; }
DBID id_of_thing_that_threw() const { return id; }
protected:
int e;
DBID id; // some user-defined type
};
</pre></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt03ch07.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt03ch07.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt03ch07s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 7. Exceptions </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Cancellation</td></tr></table></div></body></html>

4
libstdc++-v3/doc/html/manual/bk01pt03ch07s03.html Normal file
View File

@ -0,0 +1,4 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Cancellation</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt03ch07.html" title="Chapter 7. Exceptions" /><link rel="prev" href="bk01pt03ch07s02.html" title="Adding Data to Exceptions" /><link rel="next" href="bk01pt03ch08.html" title="Chapter 8. Concept Checking" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Cancellation</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt03ch07s02.html">Prev</a> </td><th width="60%" align="center">Chapter 7. Exceptions</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt03ch08.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.diagnostics.exceptions.cancellation"></a>Cancellation</h2></div></div></div><p>
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt03ch07s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt03ch07.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt03ch08.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Adding Data to Exceptions </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 8. Concept Checking</td></tr></table></div></body></html>

39
libstdc++-v3/doc/html/manual/bk01pt03ch08.html Normal file
View File

@ -0,0 +1,39 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 8. Concept Checking</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="diagnostics.html" title="Part III. Diagnostics" /><link rel="prev" href="bk01pt03ch07s03.html" title="Cancellation" /><link rel="next" href="utilities.html" title="Part IV. Utilities" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 8. Concept Checking</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt03ch07s03.html">Prev</a> </td><th width="60%" align="center">Part III. Diagnostics</th><td width="20%" align="right"> <a accesskey="n" href="utilities.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.diagnostics.concept_checking"></a>Chapter 8. Concept Checking</h2></div></div></div><p>
In 1999, SGI added “<span class="quote">concept checkers</span>” to their
implementation of the STL: code which checked the template
parameters of instantiated pieces of the STL, in order to insure
that the parameters being used met the requirements of the
standard. For example, the Standard requires that types passed as
template parameters to <code class="classname">vector</code> be
"Assignable" (which means what you think it means). The
checking was done during compilation, and none of the code was
executed at runtime.
</p><p>
Unfortunately, the size of the compiler files grew significantly
as a result. The checking code itself was cumbersome. And bugs
were found in it on more than one occasion.
</p><p>
The primary author of the checking code, Jeremy Siek, had already
started work on a replacement implementation. The new code has been
formally reviewed and accepted into
<a class="ulink" href="http://www.boost.org/libs/concept_check/concept_check.htm" target="_top">the
Boost libraries</a>, and we are pleased to incorporate it into the
GNU C++ library.
</p><p>
The new version imposes a much smaller space overhead on the generated
object file. The checks are also cleaner and easier to read and
understand.
</p><p>
They are off by default for all versions of GCC.
They can be enabled at configure time with
<a class="ulink" href="../configopts.html" target="_top"><code class="literal">--enable-concept-checks</code></a>.
You can enable them on a per-translation-unit basis with
<code class="literal">-D_GLIBCXX_CONCEPT_CHECKS</code>.
</p><p>
Please note that the upcoming C++ standard has first-class
support for template parameter constraints based on concepts in the core
language. This will obviate the need for the library-simulated concept
checking described above.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt03ch07s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="diagnostics.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="utilities.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Cancellation </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part IV. Utilities</td></tr></table></div></body></html>

9
libstdc++-v3/doc/html/manual/bk01pt04ch09.html Normal file
View File

@ -0,0 +1,9 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 9. Functors</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="utilities.html" title="Part IV. Utilities" /><link rel="prev" href="utilities.html" title="Part IV. Utilities" /><link rel="next" href="bk01pt04ch10.html" title="Chapter 10. Pairs" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 9. Functors</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="utilities.html">Prev</a> </td><th width="60%" align="center">Part IV. Utilities</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt04ch10.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.util.functors"></a>Chapter 9. Functors</h2></div></div></div><p>If you don't know what functors are, you're not alone. Many people
get slightly the wrong idea. In the interest of not reinventing
the wheel, we will refer you to the introduction to the functor
concept written by SGI as part of their STL, in
<a class="ulink" href="http://www.sgi.com/tech/stl/functors.html" target="_top">their
http://www.sgi.com/tech/stl/functors.html</a>.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="utilities.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="utilities.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt04ch10.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part IV. Utilities </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 10. Pairs</td></tr></table></div></body></html>

39
libstdc++-v3/doc/html/manual/bk01pt04ch10.html Normal file
View File

@ -0,0 +1,39 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 10. Pairs</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="utilities.html" title="Part IV. Utilities" /><link rel="prev" href="bk01pt04ch09.html" title="Chapter 9. Functors" /><link rel="next" href="bk01pt04ch11.html" title="Chapter 11. Memory" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 10. Pairs</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt04ch09.html">Prev</a> </td><th width="60%" align="center">Part IV. Utilities</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt04ch11.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.util.pairs"></a>Chapter 10. Pairs</h2></div></div></div><p>The <code class="code">pair&lt;T1,T2&gt;</code> is a simple and handy way to
carry around a pair of objects. One is of type T1, and another of
type T2; they may be the same type, but you don't get anything
extra if they are. The two members can be accessed directly, as
<code class="code">.first</code> and <code class="code">.second</code>.
</p><p>Construction is simple. The default ctor initializes each member
with its respective default ctor. The other simple ctor,
</p><pre class="programlisting">
pair (const T1&amp; x, const T2&amp; y);
</pre><p>does what you think it does, <code class="code">first</code> getting <code class="code">x</code>
and <code class="code">second</code> getting <code class="code">y</code>.
</p><p>There is a copy constructor, but it requires that your compiler
handle member function templates:
</p><pre class="programlisting">
template &lt;class U, class V&gt; pair (const pair&lt;U,V&gt;&amp; p);
</pre><p>The compiler will convert as necessary from U to T1 and from
V to T2 in order to perform the respective initializations.
</p><p>The comparison operators are done for you. Equality
of two <code class="code">pair&lt;T1,T2&gt;</code>s is defined as both <code class="code">first</code>
members comparing equal and both <code class="code">second</code> members comparing
equal; this simply delegates responsibility to the respective
<code class="code">operator==</code> functions (for types like MyClass) or builtin
comparisons (for types like int, char, etc).
</p><p>
The less-than operator is a bit odd the first time you see it. It
is defined as evaluating to:
</p><pre class="programlisting">
x.first &lt; y.first ||
( !(y.first &lt; x.first) &amp;&amp; x.second &lt; y.second )
</pre><p>The other operators are not defined using the <code class="code">rel_ops</code>
functions above, but their semantics are the same.
</p><p>Finally, there is a template function called <code class="function">make_pair</code>
that takes two references-to-const objects and returns an
instance of a pair instantiated on their respective types:
</p><pre class="programlisting">
pair&lt;int,MyClass&gt; p = make_pair(4,myobject);
</pre></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt04ch09.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="utilities.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt04ch11.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 9. Functors </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 11. Memory</td></tr></table></div></body></html>

346
libstdc++-v3/doc/html/manual/bk01pt04ch11.html Normal file
View File

@ -0,0 +1,346 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 11. Memory</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="utilities.html" title="Part IV. Utilities" /><link rel="prev" href="bk01pt04ch10.html" title="Chapter 10. Pairs" /><link rel="next" href="auto_ptr.html" title="auto_ptr" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 11. Memory</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt04ch10.html">Prev</a> </td><th width="60%" align="center">Part IV. Utilities</th><td width="20%" align="right"> <a accesskey="n" href="auto_ptr.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.util.memory"></a>Chapter 11. Memory</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt04ch11.html#manual.util.memory.allocator">Allocators</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt04ch11.html#allocator.req">Requirements</a></span></dt><dt><span class="sect2"><a href="bk01pt04ch11.html#allocator.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="bk01pt04ch11.html#allocator.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="bk01pt04ch11.html#allocator.using">Using a Specific Allocator</a></span></dt><dt><span class="sect2"><a href="bk01pt04ch11.html#allocator.custom">Custom Allocators</a></span></dt><dt><span class="sect2"><a href="bk01pt04ch11.html#allocator.ext">Extension Allocators</a></span></dt></dl></dd><dt><span class="sect1"><a href="auto_ptr.html">auto_ptr</a></span></dt><dd><dl><dt><span class="sect2"><a href="auto_ptr.html#auto_ptr.limitations">Limitations</a></span></dt><dt><span class="sect2"><a href="auto_ptr.html#auto_ptr.using">Use in Containers</a></span></dt></dl></dd><dt><span class="sect1"><a href="shared_ptr.html">shared_ptr</a></span></dt><dd><dl><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.req">Requirements</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.using">Use</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.ack">Acknowledgments</a></span></dt></dl></dd></dl></div><p>
Memory contains three general areas. First, function and operator
calls via <code class="function">new</code> and <code class="function">delete</code>
operator or member function calls. Second, allocation via
<code class="classname">allocator</code>. And finally, smart pointer and
intelligent pointer abstractions.
</p><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.util.memory.allocator"></a>Allocators</h2></div></div></div><p>
Memory management for Standard Library entities is encapsulated in a
class template called <code class="classname">allocator</code>. The
<code class="classname">allocator</code> abstraction is used throughout the
library in <code class="classname">string</code>, container classes,
algorithnms, and parts of iostreams. This class, and base classes of
it, are the superset of available free store (“<span class="quote">heap</span>”)
management classes.
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.req"></a>Requirements</h3></div></div></div><p>
The C++ standard only gives a few directives in this area:
</p><div class="itemizedlist"><ul type="disc"><li><p>
When you add elements to a container, and the container must
allocate more memory to hold them, the container makes the
request via its <span class="type">Allocator</span> template
parameter, which is usually aliased to
<span class="type">allocator_type</span>. This includes adding chars
to the string class, which acts as a regular STL container in
this respect.
</p></li><li><p>
The default <span class="type">Allocator</span> argument of every
container-of-T is <code class="classname">allocator&lt;T&gt;</code>.
</p></li><li><p>
The interface of the <code class="classname">allocator&lt;T&gt;</code> class is
extremely simple. It has about 20 public declarations (nested
typedefs, member functions, etc), but the two which concern us most
are:
</p><pre class="programlisting">
T* allocate (size_type n, const void* hint = 0);
void deallocate (T* p, size_type n);
</pre><p>
The <code class="varname">n</code> arguments in both those
functions is a <span class="emphasis"><em>count</em></span> of the number of
<span class="type">T</span>'s to allocate space for, <span class="emphasis"><em>not their
total size</em></span>.
(This is a simplification; the real signatures use nested typedefs.)
</p></li><li><p>
The storage is obtained by calling <code class="function">::operator
new</code>, but it is unspecified when or how
often this function is called. The use of the
<code class="varname">hint</code> is unspecified, but intended as an
aid to locality if an implementation so
desires. <code class="constant">[20.4.1.1]/6</code>
</p></li></ul></div><p>
Complete details cam be found in the C++ standard, look in
<code class="constant">[20.4 Memory]</code>.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.design_issues"></a>Design Issues</h3></div></div></div><p>
The easiest way of fulfilling the requirements is to call
<code class="function">operator new</code> each time a container needs
memory, and to call <code class="function">operator delete</code> each time
the container releases memory. This method may be <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00105.html" target="_top">slower</a>
than caching the allocations and re-using previously-allocated
memory, but has the advantage of working correctly across a wide
variety of hardware and operating systems, including large
clusters. The <code class="classname">__gnu_cxx::new_allocator</code>
implements the simple operator new and operator delete semantics,
while <code class="classname">__gnu_cxx::malloc_allocator</code>
implements much the same thing, only with the C language functions
<code class="function">std::malloc</code> and <code class="function">free</code>.
</p><p>
Another approach is to use intelligence within the allocator
class to cache allocations. This extra machinery can take a variety
of forms: a bitmap index, an index into an exponentially increasing
power-of-two-sized buckets, or simpler fixed-size pooling cache.
The cache is shared among all the containers in the program: when
your program's <code class="classname">std::vector&lt;int&gt;</code> gets
cut in half and frees a bunch of its storage, that memory can be
reused by the private
<code class="classname">std::list&lt;WonkyWidget&gt;</code> brought in from
a KDE library that you linked against. And operators
<code class="function">new</code> and <code class="function">delete</code> are not
always called to pass the memory on, either, which is a speed
bonus. Examples of allocators that use these techniques are
<code class="classname">__gnu_cxx::bitmap_allocator</code>,
<code class="classname">__gnu_cxx::pool_allocator</code>, and
<code class="classname">__gnu_cxx::__mt_alloc</code>.
</p><p>
Depending on the implementation techniques used, the underlying
operating system, and compilation environment, scaling caching
allocators can be tricky. In particular, order-of-destruction and
order-of-creation for memory pools may be difficult to pin down
with certainty, which may create problems when used with plugins
or loading and unloading shared objects in memory. As such, using
caching allocators on systems that do not support
<code class="function">abi::__cxa_atexit</code> is not recommended.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.impl"></a>Implementation</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id419220"></a>Interface Design</h4></div></div></div><p>
The only allocator interface that
is support is the standard C++ interface. As such, all STL
containers have been adjusted, and all external allocators have
been modified to support this change.
</p><p>
The class <code class="classname">allocator</code> just has typedef,
constructor, and rebind members. It inherits from one of the
high-speed extension allocators, covered below. Thus, all
allocation and deallocation depends on the base class.
</p><p>
The base class that <code class="classname">allocator</code> is derived from
may not be user-configurable.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id480984"></a>Selecting Default Allocation Policy</h4></div></div></div><p>
It's difficult to pick an allocation strategy that will provide
maximum utility, without excessively penalizing some behavior. In
fact, it's difficult just deciding which typical actions to measure
for speed.
</p><p>
Three synthetic benchmarks have been created that provide data
that is used to compare different C++ allocators. These tests are:
</p><div class="orderedlist"><ol type="1"><li><p>
Insertion.
</p><p>
Over multiple iterations, various STL container
objects have elements inserted to some maximum amount. A variety
of allocators are tested.
Test source for <a class="ulink" href="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/insert/sequence.cc?view=markup" target="_top">sequence</a>
and <a class="ulink" href="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/insert/associative.cc?view=markup" target="_top">associative</a>
containers.
</p></li><li><p>
Insertion and erasure in a multi-threaded environment.
</p><p>
This test shows the ability of the allocator to reclaim memory
on a pre-thread basis, as well as measuring thread contention
for memory resources.
Test source
<a class="ulink" href="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/insert_erase/associative.cc?view=markup" target="_top">here</a>.
</p></li><li><p>
A threaded producer/consumer model.
</p><p>
Test source for
<a class="ulink" href="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/producer_consumer/sequence.cc?view=markup" target="_top">sequence</a>
and
<a class="ulink" href="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/producer_consumer/associative.cc?view=markup" target="_top">associative</a>
containers.
</p></li></ol></div><p>
The current default choice for
<code class="classname">allocator</code> is
<code class="classname">__gnu_cxx::new_allocator</code>.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id411194"></a>Disabling Memory Caching</h4></div></div></div><p>
In use, <code class="classname">allocator</code> may allocate and
deallocate using implementation-specified strategies and
heuristics. Because of this, every call to an allocator object's
<code class="function">allocate</code> member function may not actually
call the global operator new. This situation is also duplicated
for calls to the <code class="function">deallocate</code> member
function.
</p><p>
This can be confusing.
</p><p>
In particular, this can make debugging memory errors more
difficult, especially when using third party tools like valgrind or
debug versions of <code class="function">new</code>.
</p><p>
There are various ways to solve this problem. One would be to use
a custom allocator that just called operators
<code class="function">new</code> and <code class="function">delete</code>
directly, for every allocation. (See
<code class="filename">include/ext/new_allocator.h</code>, for instance.)
However, that option would involve changing source code to use
the a non-default allocator. Another option is to force the
default allocator to remove caching and pools, and to directly
allocate with every call of <code class="function">allocate</code> and
directly deallocate with every call of
<code class="function">deallocate</code>, regardless of efficiency. As it
turns out, this last option is also available.
</p><p>
To globally disable memory caching within the library for the
default allocator, merely set
<code class="constant">GLIBCXX_FORCE_NEW</code> (with any value) in the
system's environment before running the program. If your program
crashes with <code class="constant">GLIBCXX_FORCE_NEW</code> in the
environment, it likely means that you linked against objects
built against the older library (objects which might still using the
cached allocations...).
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.using"></a>Using a Specific Allocator</h3></div></div></div><p>
You can specify different memory management schemes on a
per-container basis, by overriding the default
<span class="type">Allocator</span> template parameter. For example, an easy
(but non-portable) method of specifying that only <code class="function">malloc</code> or <code class="function">free</code>
should be used instead of the default node allocator is:
</p><pre class="programlisting">
std::list &lt;int, __gnu_cxx::malloc_allocator&lt;int&gt; &gt; malloc_list;</pre><p>
Likewise, a debugging form of whichever allocator is currently in use:
</p><pre class="programlisting">
std::deque &lt;int, __gnu_cxx::debug_allocator&lt;std::allocator&lt;int&gt; &gt; &gt; debug_deque;
</pre></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.custom"></a>Custom Allocators</h3></div></div></div><p>
Writing a portable C++ allocator would dictate that the interface
would look much like the one specified for
<code class="classname">allocator</code>. Additional member functions, but
not subtractions, would be permissible.
</p><p>
Probably the best place to start would be to copy one of the
extension allocators: say a simple one like
<code class="classname">new_allocator</code>.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.ext"></a>Extension Allocators</h3></div></div></div><p>
Several other allocators are provided as part of this
implementation. The location of the extension allocators and their
names have changed, but in all cases, functionality is
equivalent. Starting with gcc-3.4, all extension allocators are
standard style. Before this point, SGI style was the norm. Because of
this, the number of template arguments also changed. Here's a simple
chart to track the changes.
</p><p>
More details on each of these extension allocators follows.
</p><div class="orderedlist"><ol type="1"><li><p>
<code class="classname">new_allocator</code>
</p><p>
Simply wraps <code class="function">::operator new</code>
and <code class="function">::operator delete</code>.
</p></li><li><p>
<code class="classname">malloc_allocator</code>
</p><p>
Simply wraps <code class="function">malloc</code> and
<code class="function">free</code>. There is also a hook for an
out-of-memory handler (for
<code class="function">new</code>/<code class="function">delete</code> this is
taken care of elsewhere).
</p></li><li><p>
<code class="classname">array_allocator</code>
</p><p>
Allows allocations of known and fixed sizes using existing
global or external storage allocated via construction of
<code class="classname">std::tr1::array</code> objects. By using this
allocator, fixed size containers (including
<code class="classname">std::string</code>) can be used without
instances calling <code class="function">::operator new</code> and
<code class="function">::operator delete</code>. This capability
allows the use of STL abstractions without runtime
complications or overhead, even in situations such as program
startup. For usage examples, please consult the testsuite.
</p></li><li><p>
<code class="classname">debug_allocator</code>
</p><p>
A wrapper around an arbitrary allocator A. It passes on
slightly increased size requests to A, and uses the extra
memory to store size information. When a pointer is passed
to <code class="function">deallocate()</code>, the stored size is
checked, and <code class="function">assert()</code> is used to
guarantee they match.
</p></li><li><p>
<code class="classname">throw_allocator</code>
</p><p>
Includes memory tracking and marking abilities as well as hooks for
throwing exceptinos at configurable intervals (including random,
all, none).
</p></li><li><p>
<code class="classname">__pool_alloc</code>
</p><p>
A high-performance, single pool allocator. The reusable
memory is shared among identical instantiations of this type.
It calls through <code class="function">::operator new</code> to
obtain new memory when its lists run out. If a client
container requests a block larger than a certain threshold
size, then the pool is bypassed, and the allocate/deallocate
request is passed to <code class="function">::operator new</code>
directly.
</p><p>
Older versions of this class take a boolean template
parameter, called <code class="varname">thr</code>, and an integer template
parameter, called <code class="varname">inst</code>.
</p><p>
The <code class="varname">inst</code> number is used to track additional memory
pools. The point of the number is to allow multiple
instantiations of the classes without changing the semantics at
all. All three of
</p><pre class="programlisting">
typedef __pool_alloc&lt;true,0&gt; normal;
typedef __pool_alloc&lt;true,1&gt; private;
typedef __pool_alloc&lt;true,42&gt; also_private;
</pre><p>
behave exactly the same way. However, the memory pool for each type
(and remember that different instantiations result in different types)
remains separate.
</p><p>
The library uses <span class="emphasis"><em>0</em></span> in all its instantiations. If you
wish to keep separate free lists for a particular purpose, use a
different number.
</p><p>The <code class="varname">thr</code> boolean determines whether the
pool should be manipulated atomically or not. When
<code class="varname">thr</code> = <code class="constant">true</code>, the allocator
is is threadsafe, while <code class="varname">thr</code> =
<code class="constant">false</code>, and is slightly faster but unsafe for
multiple threads.
</p><p>
For thread-enabled configurations, the pool is locked with a
single big lock. In some situations, this implementation detail
may result in severe performance degredation.
</p><p>
(Note that the GCC thread abstraction layer allows us to provide
safe zero-overhead stubs for the threading routines, if threads
were disabled at configuration time.)
</p></li><li><p>
<code class="classname">__mt_alloc</code>
</p><p>
A high-performance fixed-size allocator with
exponentially-increasing allocations. It has its own
documentation, found <a class="ulink" href="../ext/mt_allocator.html" target="_top">here</a>.
</p></li><li><p>
<code class="classname">bitmap_allocator</code>
</p><p>
A high-performance allocator that uses a bit-map to keep track
of the used and unused memory locations. It has its own
documentation, found <a class="ulink" href="../ext/ballocator_doc.html" target="_top">here</a>.
</p></li></ol></div></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id413478"></a><p><span class="title"><i>
ISO/IEC 14882:1998 Programming languages - C++
</i>. </span>
isoc++_1998
<span class="pagenums">20.4 Memory. </span></p></div><div class="biblioentry"><a id="id415484"></a><p><span class="title"><i>The Standard Librarian: What Are Allocators Good
</i>. </span>
austernm
<span class="author"><span class="firstname">Matt</span> <span class="surname">Austern</span>. </span><span class="publisher"><span class="publishername">
C/C++ Users Journal
. </span></span><span class="biblioid">
<a class="ulink" href="http://www.cuj.com/documents/s=8000/cujcexp1812austern/" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id398891"></a><p><span class="title"><i>The Hoard Memory Allocator</i>. </span>
emeryb
<span class="author"><span class="firstname">Emery</span> <span class="surname">Berger</span>. </span><span class="biblioid">
<a class="ulink" href="http://www.cs.umass.edu/~emery/hoard/" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id413375"></a><p><span class="title"><i>Reconsidering Custom Memory Allocation</i>. </span>
bergerzorn
<span class="author"><span class="firstname">Emery</span> <span class="surname">Berger</span>. </span><span class="author"><span class="firstname">Ben</span> <span class="surname">Zorn</span>. </span><span class="author"><span class="firstname">Kathryn</span> <span class="surname">McKinley</span>. </span><span class="copyright">Copyright © 2002 OOPSLA. </span><span class="biblioid">
<a class="ulink" href="http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id425682"></a><p><span class="title"><i>Allocator Types</i>. </span>
kreftlanger
<span class="author"><span class="firstname">Klaus</span> <span class="surname">Kreft</span>. </span><span class="author"><span class="firstname">Angelika</span> <span class="surname">Langer</span>. </span><span class="publisher"><span class="publishername">
C/C++ Users Journal
. </span></span><span class="biblioid">
<a class="ulink" href="http://www.langer.camelot.de/Articles/C++Report/Allocators/Allocators.html" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id420837"></a><p><span class="title"><i>The C++ Programming Language</i>. </span>
tcpl
<span class="author"><span class="firstname">Bjarne</span> <span class="surname">Stroustrup</span>. </span><span class="copyright">Copyright © 2000 . </span><span class="pagenums">19.4 Allocators. </span><span class="publisher"><span class="publishername">
Addison Wesley
. </span></span></p></div><div class="biblioentry"><a id="id423539"></a><p><span class="title"><i>Yalloc: A Recycling C++ Allocator</i>. </span>
yenf
<span class="author"><span class="firstname">Felix</span> <span class="surname">Yen</span>. </span><span class="copyright">Copyright © . </span><span class="biblioid">
<a class="ulink" href="http://home.earthlink.net/~brimar/yalloc/" target="_top">
</a>
. </span></p></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt04ch10.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="utilities.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="auto_ptr.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 10. Pairs </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> auto_ptr</td></tr></table></div></body></html>

4
libstdc++-v3/doc/html/manual/bk01pt04ch12.html Normal file
View File

@ -0,0 +1,4 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 12. Traits</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="utilities.html" title="Part IV. Utilities" /><link rel="prev" href="shared_ptr.html" title="shared_ptr" /><link rel="next" href="strings.html" title="Part V. Strings" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 12. Traits</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="shared_ptr.html">Prev</a> </td><th width="60%" align="center">Part IV. Utilities</th><td width="20%" align="right"> <a accesskey="n" href="strings.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.util.traits"></a>Chapter 12. Traits</h2></div></div></div><p>
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="shared_ptr.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="utilities.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="strings.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">shared_ptr </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part V. Strings</td></tr></table></div></body></html>

89
libstdc++-v3/doc/html/manual/bk01pt05ch13.html Normal file
View File

@ -0,0 +1,89 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 13. String Classes</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="strings.html" title="Part V. Strings" /><link rel="prev" href="strings.html" title="Part V. Strings" /><link rel="next" href="bk01pt05ch13s02.html" title="Case Sensivitity" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 13. String Classes</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="strings.html">Prev</a> </td><th width="60%" align="center">Part V. Strings</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt05ch13s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.strings.string"></a>Chapter 13. String Classes</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt05ch13.html#strings.string.simple">Simple Transformations</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s02.html">Case Sensivitity</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s03.html">Arbitrary Character Types</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s04.html">Tokenizing</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s05.html">Shrink to Fit</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s06.html">CString (MFC)</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="strings.string.simple"></a>Simple Transformations</h2></div></div></div><p>
Here are Standard, simple, and portable ways to perform common
transformations on a <code class="code">string</code> instance, such as
"convert to all upper case." The word transformations
is especially apt, because the standard template function
<code class="code">transform&lt;&gt;</code> is used.
</p><p>
This code will go through some iterations. Here's a simiple
version:
</p><pre class="programlisting">
#include &lt;string&gt;
#include &lt;algorithm&gt;
#include &lt;cctype&gt; // old &lt;ctype.h&gt;
struct ToLower
{
char operator() (char c) const { return std::tolower(c); }
};
struct ToUpper
{
char operator() (char c) const { return std::toupper(c); }
};
int main()
{
std::string s ("Some Kind Of Initial Input Goes Here");
// Change everything into upper case
std::transform (s.begin(), s.end(), s.begin(), ToUpper());
// Change everything into lower case
std::transform (s.begin(), s.end(), s.begin(), ToLower());
// Change everything back into upper case, but store the
// result in a different string
std::string capital_s;
capital_s.resize(s.size());
std::transform (s.begin(), s.end(), capital_s.begin(), ToUpper());
}
</pre><p>
<span class="emphasis"><em>Note</em></span> that these calls all
involve the global C locale through the use of the C functions
<code class="code">toupper/tolower</code>. This is absolutely guaranteed to work --
but <span class="emphasis"><em>only</em></span> if the string contains <span class="emphasis"><em>only</em></span> characters
from the basic source character set, and there are <span class="emphasis"><em>only</em></span>
96 of those. Which means that not even all English text can be
represented (certain British spellings, proper names, and so forth).
So, if all your input forevermore consists of only those 96
characters (hahahahahaha), then you're done.
</p><p><span class="emphasis"><em>Note</em></span> that the
<code class="code">ToUpper</code> and <code class="code">ToLower</code> function objects
are needed because <code class="code">toupper</code> and <code class="code">tolower</code>
are overloaded names (declared in <code class="code">&lt;cctype&gt;</code> and
<code class="code">&lt;locale&gt;</code>) so the template-arguments for
<code class="code">transform&lt;&gt;</code> cannot be deduced, as explained in
<a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-11/msg00180.html" target="_top">this
message</a>.
At minimum, you can write short wrappers like
</p><pre class="programlisting">
char toLower (char c)
{
return std::tolower(c);
} </pre><p>The correct method is to use a facet for a particular locale
and call its conversion functions. These are discussed more in
Chapter 22; the specific part is
<a class="ulink" href="../22_locale/howto.html#7" target="_top">Correct Transformations</a>,
which shows the final version of this code. (Thanks to James Kanze
for assistance and suggestions on all of this.)
</p><p>Another common operation is trimming off excess whitespace. Much
like transformations, this task is trivial with the use of string's
<code class="code">find</code> family. These examples are broken into multiple
statements for readability:
</p><pre class="programlisting">
std::string str (" \t blah blah blah \n ");
// trim leading whitespace
string::size_type notwhite = str.find_first_not_of(" \t\n");
str.erase(0,notwhite);
// trim trailing whitespace
notwhite = str.find_last_not_of(" \t\n");
str.erase(notwhite+1); </pre><p>Obviously, the calls to <code class="code">find</code> could be inserted directly
into the calls to <code class="code">erase</code>, in case your compiler does not
optimize named temporaries out of existence.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="strings.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="strings.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt05ch13s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part V. Strings </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Case Sensivitity</td></tr></table></div></body></html>

40
libstdc++-v3/doc/html/manual/bk01pt05ch13s02.html Normal file
View File

@ -0,0 +1,40 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Case Sensivitity</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /><link rel="prev" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /><link rel="next" href="bk01pt05ch13s03.html" title="Arbitrary Character Types" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Case Sensivitity</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt05ch13.html">Prev</a> </td><th width="60%" align="center">Chapter 13. String Classes</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt05ch13s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="strings.string.case"></a>Case Sensivitity</h2></div></div></div><p>
</p><p>The well-known-and-if-it-isn't-well-known-it-ought-to-be
<a class="ulink" href="http://www.gotw.ca/gotw/" target="_top">Guru of the Week</a>
discussions held on Usenet covered this topic in January of 1998.
Briefly, the challenge was, “<span class="quote">write a 'ci_string' class which
is identical to the standard 'string' class, but is
case-insensitive in the same way as the (common but nonstandard)
C function stricmp()</span>”.
</p><pre class="programlisting">
ci_string s( "AbCdE" );
// case insensitive
assert( s == "abcde" );
assert( s == "ABCDE" );
// still case-preserving, of course
assert( strcmp( s.c_str(), "AbCdE" ) == 0 );
assert( strcmp( s.c_str(), "abcde" ) != 0 ); </pre><p>The solution is surprisingly easy. The original answer was
posted on Usenet, and a revised version appears in Herb Sutter's
book <span class="emphasis"><em>Exceptional C++</em></span> and on his website as <a class="ulink" href="http://www.gotw.ca/gotw/029.htm" target="_top">GotW 29</a>.
</p><p>See? Told you it was easy!</p><p>
<span class="emphasis"><em>Added June 2000:</em></span> The May 2000 issue of C++
Report contains a fascinating <a class="ulink" href="http://lafstern.org/matt/col2_new.pdf" target="_top"> article</a> by
Matt Austern (yes, <span class="emphasis"><em>the</em></span> Matt Austern) on why
case-insensitive comparisons are not as easy as they seem, and
why creating a class is the <span class="emphasis"><em>wrong</em></span> way to go
about it in production code. (The GotW answer mentions one of
the principle difficulties; his article mentions more.)
</p><p>Basically, this is "easy" only if you ignore some things,
things which may be too important to your program to ignore. (I chose
to ignore them when originally writing this entry, and am surprised
that nobody ever called me on it...) The GotW question and answer
remain useful instructional tools, however.
</p><p><span class="emphasis"><em>Added September 2000:</em></span> James Kanze provided a link to a
<a class="ulink" href="http://www.unicode.org/unicode/reports/tr21/" target="_top">Unicode
Technical Report discussing case handling</a>, which provides some
very good information.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt05ch13.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt05ch13.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt05ch13s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 13. String Classes </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Arbitrary Character Types</td></tr></table></div></body></html>

57
libstdc++-v3/doc/html/manual/bk01pt05ch13s03.html Normal file
View File

@ -0,0 +1,57 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Arbitrary Character Types</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /><link rel="prev" href="bk01pt05ch13s02.html" title="Case Sensivitity" /><link rel="next" href="bk01pt05ch13s04.html" title="Tokenizing" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Arbitrary Character Types</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt05ch13s02.html">Prev</a> </td><th width="60%" align="center">Chapter 13. String Classes</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt05ch13s04.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="strings.string.character_types"></a>Arbitrary Character Types</h2></div></div></div><p>
</p><p>The <code class="code">std::basic_string</code> is tantalizingly general, in that
it is parameterized on the type of the characters which it holds.
In theory, you could whip up a Unicode character class and instantiate
<code class="code">std::basic_string&lt;my_unicode_char&gt;</code>, or assuming
that integers are wider than characters on your platform, maybe just
declare variables of type <code class="code">std::basic_string&lt;int&gt;</code>.
</p><p>That's the theory. Remember however that basic_string has additional
type parameters, which take default arguments based on the character
type (called <code class="code">CharT</code> here):
</p><pre class="programlisting">
template &lt;typename CharT,
typename Traits = char_traits&lt;CharT&gt;,
typename Alloc = allocator&lt;CharT&gt; &gt;
class basic_string { .... };</pre><p>Now, <code class="code">allocator&lt;CharT&gt;</code> will probably Do The Right
Thing by default, unless you need to implement your own allocator
for your characters.
</p><p>But <code class="code">char_traits</code> takes more work. The char_traits
template is <span class="emphasis"><em>declared</em></span> but not <span class="emphasis"><em>defined</em></span>.
That means there is only
</p><pre class="programlisting">
template &lt;typename CharT&gt;
struct char_traits
{
static void foo (type1 x, type2 y);
...
};</pre><p>and functions such as char_traits&lt;CharT&gt;::foo() are not
actually defined anywhere for the general case. The C++ standard
permits this, because writing such a definition to fit all possible
CharT's cannot be done.
</p><p>The C++ standard also requires that char_traits be specialized for
instantiations of <code class="code">char</code> and <code class="code">wchar_t</code>, and it
is these template specializations that permit entities like
<code class="code">basic_string&lt;char,char_traits&lt;char&gt;&gt;</code> to work.
</p><p>If you want to use character types other than char and wchar_t,
such as <code class="code">unsigned char</code> and <code class="code">int</code>, you will
need suitable specializations for them. For a time, in earlier
versions of GCC, there was a mostly-correct implementation that
let programmers be lazy but it broke under many situations, so it
was removed. GCC 3.4 introduced a new implementation that mostly
works and can be specialized even for <code class="code">int</code> and other
built-in types.
</p><p>If you want to use your own special character class, then you have
<a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00163.html" target="_top">a lot
of work to do</a>, especially if you with to use i18n features
(facets require traits information but don't have a traits argument).
</p><p>Another example of how to specialize char_traits was given <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00260.html" target="_top">on the
mailing list</a> and at a later date was put into the file <code class="code">
include/ext/pod_char_traits.h</code>. We agree
that the way it's used with basic_string (scroll down to main())
doesn't look nice, but that's because <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00236.html" target="_top">the
nice-looking first attempt</a> turned out to <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00242.html" target="_top">not
be conforming C++</a>, due to the rule that CharT must be a POD.
(See how tricky this is?)
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt05ch13s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt05ch13.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt05ch13s04.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Case Sensivitity </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Tokenizing</td></tr></table></div></body></html>

85
libstdc++-v3/doc/html/manual/bk01pt05ch13s04.html Normal file
View File

@ -0,0 +1,85 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Tokenizing</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /><link rel="prev" href="bk01pt05ch13s03.html" title="Arbitrary Character Types" /><link rel="next" href="bk01pt05ch13s05.html" title="Shrink to Fit" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Tokenizing</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt05ch13s03.html">Prev</a> </td><th width="60%" align="center">Chapter 13. String Classes</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt05ch13s05.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="strings.string.token"></a>Tokenizing</h2></div></div></div><p>
</p><p>The Standard C (and C++) function <code class="code">strtok()</code> leaves a lot to
be desired in terms of user-friendliness. It's unintuitive, it
destroys the character string on which it operates, and it requires
you to handle all the memory problems. But it does let the client
code decide what to use to break the string into pieces; it allows
you to choose the "whitespace," so to speak.
</p><p>A C++ implementation lets us keep the good things and fix those
annoyances. The implementation here is more intuitive (you only
call it once, not in a loop with varying argument), it does not
affect the original string at all, and all the memory allocation
is handled for you.
</p><p>It's called stringtok, and it's a template function. Sources are
as below, in a less-portable form than it could be, to keep this
example simple (for example, see the comments on what kind of
string it will accept).
</p><pre class="programlisting">
#include &lt;string&gt;
template &lt;typename Container&gt;
void
stringtok(Container &amp;container, string const &amp;in,
const char * const delimiters = " \t\n")
{
const string::size_type len = in.length();
string::size_type i = 0;
while (i &lt; len)
{
// Eat leading whitespace
i = in.find_first_not_of(delimiters, i);
if (i == string::npos)
return; // Nothing left but white space
// Find the end of the token
string::size_type j = in.find_first_of(delimiters, i);
// Push token
if (j == string::npos)
{
container.push_back(in.substr(i));
return;
}
else
container.push_back(in.substr(i, j-i));
// Set up for next loop
i = j + 1;
}
}
</pre><p>
The author uses a more general (but less readable) form of it for
parsing command strings and the like. If you compiled and ran this
code using it:
</p><pre class="programlisting">
std::list&lt;string&gt; ls;
stringtok (ls, " this \t is\t\n a test ");
for (std::list&lt;string&gt;const_iterator i = ls.begin();
i != ls.end(); ++i)
{
std::cerr &lt;&lt; ':' &lt;&lt; (*i) &lt;&lt; ":\n";
} </pre><p>You would see this as output:
</p><pre class="programlisting">
:this:
:is:
:a:
:test: </pre><p>with all the whitespace removed. The original <code class="code">s</code> is still
available for use, <code class="code">ls</code> will clean up after itself, and
<code class="code">ls.size()</code> will return how many tokens there were.
</p><p>As always, there is a price paid here, in that stringtok is not
as fast as strtok. The other benefits usually outweigh that, however.
<a class="ulink" href="stringtok_std_h.txt" target="_top">Another version of stringtok is given
here</a>, suggested by Chris King and tweaked by Petr Prikryl,
and this one uses the
transformation functions mentioned below. If you are comfortable
with reading the new function names, this version is recommended
as an example.
</p><p><span class="emphasis"><em>Added February 2001:</em></span> Mark Wilden pointed out that the
standard <code class="code">std::getline()</code> function can be used with standard
<a class="ulink" href="../27_io/howto.html" target="_top">istringstreams</a> to perform
tokenizing as well. Build an istringstream from the input text,
and then use std::getline with varying delimiters (the three-argument
signature) to extract tokens into a string.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt05ch13s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt05ch13.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt05ch13s05.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Arbitrary Character Types </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Shrink to Fit</td></tr></table></div></body></html>

15
libstdc++-v3/doc/html/manual/bk01pt05ch13s05.html Normal file
View File

@ -0,0 +1,15 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Shrink to Fit</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /><link rel="prev" href="bk01pt05ch13s04.html" title="Tokenizing" /><link rel="next" href="bk01pt05ch13s06.html" title="CString (MFC)" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Shrink to Fit</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt05ch13s04.html">Prev</a> </td><th width="60%" align="center">Chapter 13. String Classes</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt05ch13s06.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="strings.string.shrink"></a>Shrink to Fit</h2></div></div></div><p>
</p><p>From GCC 3.4 calling <code class="code">s.reserve(res)</code> on a
<code class="code">string s</code> with <code class="code">res &lt; s.capacity()</code> will
reduce the string's capacity to <code class="code">std::max(s.size(), res)</code>.
</p><p>This behaviour is suggested, but not required by the standard. Prior
to GCC 3.4 the following alternative can be used instead
</p><pre class="programlisting">
std::string(str.data(), str.size()).swap(str);
</pre><p>This is similar to the idiom for reducing a <code class="code">vector</code>'s
memory usage (see <a class="ulink" href="../faq/index.html#5_9" target="_top">FAQ 5.9</a>) but
the regular copy constructor cannot be used because libstdc++'s
<code class="code">string</code> is Copy-On-Write.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt05ch13s04.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt05ch13.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt05ch13s06.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Tokenizing </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> CString (MFC)</td></tr></table></div></body></html>

91
libstdc++-v3/doc/html/manual/bk01pt05ch13s06.html Normal file
View File

@ -0,0 +1,91 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>CString (MFC)</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /><link rel="prev" href="bk01pt05ch13s05.html" title="Shrink to Fit" /><link rel="next" href="localization.html" title="Part VI. Localization" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">CString (MFC)</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt05ch13s05.html">Prev</a> </td><th width="60%" align="center">Chapter 13. String Classes</th><td width="20%" align="right"> <a accesskey="n" href="localization.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="strings.string.Cstring"></a>CString (MFC)</h2></div></div></div><p>
</p><p>A common lament seen in various newsgroups deals with the Standard
string class as opposed to the Microsoft Foundation Class called
CString. Often programmers realize that a standard portable
answer is better than a proprietary nonportable one, but in porting
their application from a Win32 platform, they discover that they
are relying on special functions offered by the CString class.
</p><p>Things are not as bad as they seem. In
<a class="ulink" href="http://gcc.gnu.org/ml/gcc/1999-04n/msg00236.html" target="_top">this
message</a>, Joe Buck points out a few very important things:
</p><div class="itemizedlist"><ul type="disc"><li><p>The Standard <code class="code">string</code> supports all the operations
that CString does, with three exceptions.
</p></li><li><p>Two of those exceptions (whitespace trimming and case
conversion) are trivial to implement. In fact, we do so
on this page.
</p></li><li><p>The third is <code class="code">CString::Format</code>, which allows formatting
in the style of <code class="code">sprintf</code>. This deserves some mention:
</p></li></ul></div><p>
The old libg++ library had a function called form(), which did much
the same thing. But for a Standard solution, you should use the
stringstream classes. These are the bridge between the iostream
hierarchy and the string class, and they operate with regular
streams seamlessly because they inherit from the iostream
hierarchy. An quick example:
</p><pre class="programlisting">
#include &lt;iostream&gt;
#include &lt;string&gt;
#include &lt;sstream&gt;
string f (string&amp; incoming) // incoming is "foo N"
{
istringstream incoming_stream(incoming);
string the_word;
int the_number;
incoming_stream &gt;&gt; the_word // extract "foo"
&gt;&gt; the_number; // extract N
ostringstream output_stream;
output_stream &lt;&lt; "The word was " &lt;&lt; the_word
&lt;&lt; " and 3*N was " &lt;&lt; (3*the_number);
return output_stream.str();
} </pre><p>A serious problem with CString is a design bug in its memory
allocation. Specifically, quoting from that same message:
</p><pre class="programlisting">
CString suffers from a common programming error that results in
poor performance. Consider the following code:
CString n_copies_of (const CString&amp; foo, unsigned n)
{
CString tmp;
for (unsigned i = 0; i &lt; n; i++)
tmp += foo;
return tmp;
}
This function is O(n^2), not O(n). The reason is that each +=
causes a reallocation and copy of the existing string. Microsoft
applications are full of this kind of thing (quadratic performance
on tasks that can be done in linear time) -- on the other hand,
we should be thankful, as it's created such a big market for high-end
ix86 hardware. :-)
If you replace CString with string in the above function, the
performance is O(n).
</pre><p>Joe Buck also pointed out some other things to keep in mind when
comparing CString and the Standard string class:
</p><div class="itemizedlist"><ul type="disc"><li><p>CString permits access to its internal representation; coders
who exploited that may have problems moving to <code class="code">string</code>.
</p></li><li><p>Microsoft ships the source to CString (in the files
MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation
bug and rebuild your MFC libraries.
<span class="emphasis"><em><span class="emphasis"><em>Note:</em></span> It looks like the CString shipped
with VC++6.0 has fixed this, although it may in fact have been
one of the VC++ SPs that did it.</em></span>
</p></li><li><p><code class="code">string</code> operations like this have O(n) complexity
<span class="emphasis"><em>if the implementors do it correctly</em></span>. The libstdc++
implementors did it correctly. Other vendors might not.
</p></li><li><p>While parts of the SGI STL are used in libstdc++, their
string class is not. The SGI <code class="code">string</code> is essentially
<code class="code">vector&lt;char&gt;</code> and does not do any reference
counting like libstdc++'s does. (It is O(n), though.)
So if you're thinking about SGI's string or rope classes,
you're now looking at four possibilities: CString, the
libstdc++ string, the SGI string, and the SGI rope, and this
is all before any allocator or traits customizations! (More
choices than you can shake a stick at -- want fries with that?)
</p></li></ul></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt05ch13s05.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt05ch13.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="localization.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Shrink to Fit </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part VI. Localization</td></tr></table></div></body></html>

422
libstdc++-v3/doc/html/manual/bk01pt06ch14.html Normal file
View File

@ -0,0 +1,422 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 14. Locales</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="localization.html" title="Part VI. Localization" /><link rel="prev" href="localization.html" title="Part VI. Localization" /><link rel="next" href="bk01pt06ch15.html" title="Chapter 15. Facets aka Categories" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 14. Locales</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="localization.html">Prev</a> </td><th width="60%" align="center">Part VI. Localization</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt06ch15.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.localization.locales"></a>Chapter 14. Locales</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt06ch14.html#manual.localization.locales.locale">locale</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt06ch14.html#locales.locale.req">Requirements</a></span></dt><dt><span class="sect2"><a href="bk01pt06ch14.html#locales.locale.design">Design</a></span></dt><dt><span class="sect2"><a href="bk01pt06ch14.html#locales.locale.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="bk01pt06ch14.html#locales.locale.future">Future</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.localization.locales.locale"></a>locale</h2></div></div></div><p>
Describes the basic locale object, including nested
classes id, facet, and the reference-counted implementation object,
class _Impl.
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="locales.locale.req"></a>Requirements</h3></div></div></div><p>
Class locale is non-templatized and has two distinct types nested
inside of it:
</p><div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em>
class facet
22.1.1.1.2 Class locale::facet
</em></span>
</p></blockquote></div><p>
Facets actually implement locale functionality. For instance, a facet
called numpunct is the data objects that can be used to query for the
thousands separator is in the German locale.
</p><p>
Literally, a facet is strictly defined:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Dontaining the following public data member:
</p><p>
<code class="code">static locale::id id;</code>
</p></li><li><p>
Derived from another facet:
</p><p>
<code class="code">class gnu_codecvt: public std::ctype&lt;user-defined-type&gt;</code>
</p></li></ul></div><p>
Of interest in this class are the memory management options explicitly
specified as an argument to facet's constructor. Each constructor of a
facet class takes a std::size_t __refs argument: if __refs == 0, the
facet is deleted when the locale containing it is destroyed. If __refs
== 1, the facet is not destroyed, even when it is no longer
referenced.
</p><div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em>
class id
22.1.1.1.3 - Class locale::id
</em></span>
</p></blockquote></div><p>
Provides an index for looking up specific facets.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="locales.locale.design"></a>Design</h3></div></div></div><p>
The major design challenge is fitting an object-orientated and
non-global locale design ontop of POSIX and other relevant stanards,
which include the Single Unix (nee X/Open.)
</p><p>
Because C and earlier versions of POSIX falls down so completely,
portibility is an issue.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="locales.locale.impl"></a>Implementation</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="locale.impl.c"></a>Interacting with "C" locales</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
<code class="code">`locale -a`</code> displays available locales.
</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">
af_ZA
ar_AE
ar_AE.utf8
ar_BH
ar_BH.utf8
ar_DZ
ar_DZ.utf8
ar_EG
ar_EG.utf8
ar_IN
ar_IQ
ar_IQ.utf8
ar_JO
ar_JO.utf8
ar_KW
ar_KW.utf8
ar_LB
ar_LB.utf8
ar_LY
ar_LY.utf8
ar_MA
ar_MA.utf8
ar_OM
ar_OM.utf8
ar_QA
ar_QA.utf8
ar_SA
ar_SA.utf8
ar_SD
ar_SD.utf8
ar_SY
ar_SY.utf8
ar_TN
ar_TN.utf8
ar_YE
ar_YE.utf8
be_BY
be_BY.utf8
bg_BG
bg_BG.utf8
br_FR
bs_BA
C
ca_ES
ca_ES@euro
ca_ES.utf8
ca_ES.utf8@euro
cs_CZ
cs_CZ.utf8
cy_GB
da_DK
da_DK.iso885915
da_DK.utf8
de_AT
de_AT@euro
de_AT.utf8
de_AT.utf8@euro
de_BE
de_BE@euro
de_BE.utf8
de_BE.utf8@euro
de_CH
de_CH.utf8
de_DE
de_DE@euro
de_DE.utf8
de_DE.utf8@euro
de_LU
de_LU@euro
de_LU.utf8
de_LU.utf8@euro
el_GR
el_GR.utf8
en_AU
en_AU.utf8
en_BW
en_BW.utf8
en_CA
en_CA.utf8
en_DK
en_DK.utf8
en_GB
en_GB.iso885915
en_GB.utf8
en_HK
en_HK.utf8
en_IE
en_IE@euro
en_IE.utf8
en_IE.utf8@euro
en_IN
en_NZ
en_NZ.utf8
en_PH
en_PH.utf8
en_SG
en_SG.utf8
en_US
en_US.iso885915
en_US.utf8
en_ZA
en_ZA.utf8
en_ZW
en_ZW.utf8
es_AR
es_AR.utf8
es_BO
es_BO.utf8
es_CL
es_CL.utf8
es_CO
es_CO.utf8
es_CR
es_CR.utf8
es_DO
es_DO.utf8
es_EC
es_EC.utf8
es_ES
es_ES@euro
es_ES.utf8
es_ES.utf8@euro
es_GT
es_GT.utf8
es_HN
es_HN.utf8
es_MX
es_MX.utf8
es_NI
es_NI.utf8
es_PA
es_PA.utf8
es_PE
es_PE.utf8
es_PR
es_PR.utf8
es_PY
es_PY.utf8
es_SV
es_SV.utf8
es_US
es_US.utf8
es_UY
es_UY.utf8
es_VE
es_VE.utf8
et_EE
et_EE.utf8
eu_ES
eu_ES@euro
eu_ES.utf8
eu_ES.utf8@euro
fa_IR
fi_FI
fi_FI@euro
fi_FI.utf8
fi_FI.utf8@euro
fo_FO
fo_FO.utf8
fr_BE
fr_BE@euro
fr_BE.utf8
fr_BE.utf8@euro
fr_CA
fr_CA.utf8
fr_CH
fr_CH.utf8
fr_FR
fr_FR@euro
fr_FR.utf8
fr_FR.utf8@euro
fr_LU
fr_LU@euro
fr_LU.utf8
fr_LU.utf8@euro
ga_IE
ga_IE@euro
ga_IE.utf8
ga_IE.utf8@euro
gl_ES
gl_ES@euro
gl_ES.utf8
gl_ES.utf8@euro
gv_GB
gv_GB.utf8
he_IL
he_IL.utf8
hi_IN
hr_HR
hr_HR.utf8
hu_HU
hu_HU.utf8
id_ID
id_ID.utf8
is_IS
is_IS.utf8
it_CH
it_CH.utf8
it_IT
it_IT@euro
it_IT.utf8
it_IT.utf8@euro
iw_IL
iw_IL.utf8
ja_JP.eucjp
ja_JP.utf8
ka_GE
kl_GL
kl_GL.utf8
ko_KR.euckr
ko_KR.utf8
kw_GB
kw_GB.utf8
lt_LT
lt_LT.utf8
lv_LV
lv_LV.utf8
mi_NZ
mk_MK
mk_MK.utf8
mr_IN
ms_MY
ms_MY.utf8
mt_MT
mt_MT.utf8
nl_BE
nl_BE@euro
nl_BE.utf8
nl_BE.utf8@euro
nl_NL
nl_NL@euro
nl_NL.utf8
nl_NL.utf8@euro
nn_NO
nn_NO.utf8
no_NO
no_NO.utf8
oc_FR
pl_PL
pl_PL.utf8
POSIX
pt_BR
pt_BR.utf8
pt_PT
pt_PT@euro
pt_PT.utf8
pt_PT.utf8@euro
ro_RO
ro_RO.utf8
ru_RU
ru_RU.koi8r
ru_RU.utf8
ru_UA
ru_UA.utf8
se_NO
sk_SK
sk_SK.utf8
sl_SI
sl_SI.utf8
sq_AL
sq_AL.utf8
sr_YU
sr_YU@cyrillic
sr_YU.utf8
sr_YU.utf8@cyrillic
sv_FI
sv_FI@euro
sv_FI.utf8
sv_FI.utf8@euro
sv_SE
sv_SE.iso885915
sv_SE.utf8
ta_IN
te_IN
tg_TJ
th_TH
th_TH.utf8
tl_PH
tr_TR
tr_TR.utf8
uk_UA
uk_UA.utf8
ur_PK
uz_UZ
vi_VN
vi_VN.tcvn
wa_BE
wa_BE@euro
yi_US
zh_CN
zh_CN.gb18030
zh_CN.gbk
zh_CN.utf8
zh_HK
zh_HK.utf8
zh_TW
zh_TW.euctw
zh_TW.utf8
</pre></blockquote></div></li><li><p>
<code class="code">`locale`</code> displays environmental variables that
impact how locale("") will be deduced.
</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">
LANG=en_US
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=
</pre></blockquote></div></li></ul></div><p>
From Josuttis, p. 697-698, which says, that "there is only *one*
relation (of the C++ locale mechanism) to the C locale mechanism: the
global C locale is modified if a named C++ locale object is set as the
global locale" (emphasis Paolo), that is:
</p><pre class="programlisting">std::locale::global(std::locale(""));</pre><p>affects the C functions as if the following call was made:</p><pre class="programlisting">std::setlocale(LC_ALL, "");</pre><p>
On the other hand, there is *no* viceversa, that is, calling
setlocale has *no* whatsoever on the C++ locale mechanism, in
particular on the working of locale(""), which constructs the locale
object from the environment of the running program, that is, in
practice, the set of LC_ALL, LANG, etc. variable of the shell.
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="locales.locale.future"></a>Future</h3></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Locale initialization: at what point does _S_classic, _S_global
get initialized? Can named locales assume this initialization
has already taken place?
</p></li><li><p>
Document how named locales error check when filling data
members. Ie, a fr_FR locale that doesn't have
numpunct::truename(): does it use "true"? Or is it a blank
string? What's the convention?
</p></li><li><p>
Explain how locale aliasing happens. When does "de_DE" use "de"
information? What is the rule for locales composed of just an
ISO language code (say, "de") and locales with both an ISO
language code and ISO country code (say, "de_DE").
</p></li><li><p>
What should non-required facet instantiations do? If the
generic implemenation is provided, then how to end-users
provide specializations?
</p></li></ul></div></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="locales.locale.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id389722"></a><p><span class="title"><i>
The GNU C Library
</i>. </span><span class="author"><span class="firstname">Roland</span> <span class="surname">McGrath</span>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2007 FSF. </span><span class="pagenums">Chapters 6 Character Set Handling and 7 Locales and Internationalization. </span></p></div><div class="biblioentry"><a id="id418042"></a><p><span class="title"><i>
Correspondence
</i>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2002 . </span></p></div><div class="biblioentry"><a id="id495535"></a><p><span class="title"><i>
ISO/IEC 14882:1998 Programming languages - C++
</i>. </span><span class="copyright">Copyright © 1998 ISO. </span></p></div><div class="biblioentry"><a id="id434429"></a><p><span class="title"><i>
ISO/IEC 9899:1999 Programming languages - C
</i>. </span><span class="copyright">Copyright © 1999 ISO. </span></p></div><div class="biblioentry"><a id="id434447"></a><p><span class="title"><i>
System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x)
</i>. </span><span class="copyright">Copyright © 1999
The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. </span><span class="biblioid">
<a class="ulink" href="http://www.opennc.org/austin/docreg.html" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id415318"></a><p><span class="title"><i>
The C++ Programming Language, Special Edition
</i>. </span><span class="author"><span class="firstname">Bjarne</span> <span class="surname">Stroustrup</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley, Inc.. </span><span class="pagenums">Appendix D. </span><span class="publisher"><span class="publishername">
Addison Wesley
. </span></span></p></div><div class="biblioentry"><a id="id424745"></a><p><span class="title"><i>
Standard C++ IOStreams and Locales
</i>. </span><span class="subtitle">
Advanced Programmer's Guide and Reference
. </span><span class="author"><span class="firstname">Angelika</span> <span class="surname">Langer</span>. </span><span class="author"><span class="firstname">Klaus</span> <span class="surname">Kreft</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley Longman, Inc.. </span><span class="publisher"><span class="publishername">
Addison Wesley Longman
. </span></span></p></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="localization.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="localization.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt06ch15.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part VI. Localization </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 15. Facets aka Categories</td></tr></table></div></body></html>

74
libstdc++-v3/doc/html/manual/bk01pt06ch15.html Normal file
View File

@ -0,0 +1,74 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 15. Facets aka Categories</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="localization.html" title="Part VI. Localization" /><link rel="prev" href="bk01pt06ch14.html" title="Chapter 14. Locales" /><link rel="next" href="codecvt.html" title="codecvt" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 15. Facets aka Categories</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt06ch14.html">Prev</a> </td><th width="60%" align="center">Part VI. Localization</th><td width="20%" align="right"> <a accesskey="n" href="codecvt.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.localization.facet"></a>Chapter 15. Facets aka Categories</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt06ch15.html#manual.localization.facet.ctype">ctype</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt06ch15.html#facet.ctype.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="bk01pt06ch15.html#facet.ctype.future">Future</a></span></dt></dl></dd><dt><span class="sect1"><a href="codecvt.html">codecvt</a></span></dt><dd><dl><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.req">Requirements</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.design">Design</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.use">Use</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.future">Future</a></span></dt></dl></dd><dt><span class="sect1"><a href="messages.html">messages</a></span></dt><dd><dl><dt><span class="sect2"><a href="messages.html#facet.messages.req">Requirements</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.design">Design</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.use">Use</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.future">Future</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.localization.facet.ctype"></a>ctype</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.ctype.impl"></a>Implementation</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id424267"></a>Specializations</h4></div></div></div><p>
For the required specialization codecvt&lt;wchar_t, char, mbstate_t&gt; ,
conversions are made between the internal character set (always UCS4
on GNU/Linux) and whatever the currently selected locale for the
LC_CTYPE category implements.
</p><p>
The two required specializations are implemented as follows:
</p><p>
<code class="code">
ctype&lt;char&gt;
</code>
</p><p>
This is simple specialization. Implementing this was a piece of cake.
</p><p>
<code class="code">
ctype&lt;wchar_t&gt;
</code>
</p><p>
This specialization, by specifying all the template parameters, pretty
much ties the hands of implementors. As such, the implementation is
straightforward, involving mcsrtombs for the conversions between char
to wchar_t and wcsrtombs for conversions between wchar_t and char.
</p><p>
Neither of these two required specializations deals with Unicode
characters.
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.ctype.future"></a>Future</h3></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
How to deal with the global locale issue?
</p></li><li><p>
How to deal with different types than char, wchar_t? </p></li><li><p>
Overlap between codecvt/ctype: narrow/widen
</p></li><li><p>
Mask typedef in codecvt_base, argument types in codecvt. what
is know about this type?
</p></li><li><p>
Why mask* argument in codecvt?
</p></li><li><p>
Can this be made (more) generic? is there a simple way to
straighten out the configure-time mess that is a by-product of
this class?
</p></li><li><p>
Get the ctype&lt;wchar_t&gt;::mask stuff under control. Need to
make some kind of static table, and not do lookup evertime
somebody hits the do_is... functions. Too bad we can't just
redefine mask for ctype&lt;wchar_t&gt;
</p></li><li><p>
Rename abstract base class. See if just smash-overriding is a
better approach. Clarify, add sanity to naming.
</p></li></ul></div></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="facet.ctype.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id428438"></a><p><span class="title"><i>
The GNU C Library
</i>. </span><span class="author"><span class="firstname">Roland</span> <span class="surname">McGrath</span>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2007 FSF. </span><span class="pagenums">Chapters 6 Character Set Handling and 7 Locales and Internationalization. </span></p></div><div class="biblioentry"><a id="id406217"></a><p><span class="title"><i>
Correspondence
</i>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2002 . </span></p></div><div class="biblioentry"><a id="id406246"></a><p><span class="title"><i>
ISO/IEC 14882:1998 Programming languages - C++
</i>. </span><span class="copyright">Copyright © 1998 ISO. </span></p></div><div class="biblioentry"><a id="id424106"></a><p><span class="title"><i>
ISO/IEC 9899:1999 Programming languages - C
</i>. </span><span class="copyright">Copyright © 1999 ISO. </span></p></div><div class="biblioentry"><a id="id424124"></a><p><span class="title"><i>
System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x)
</i>. </span><span class="copyright">Copyright © 1999
The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. </span><span class="biblioid">
<a class="ulink" href="http://www.opennc.org/austin/docreg.html" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id483804"></a><p><span class="title"><i>
The C++ Programming Language, Special Edition
</i>. </span><span class="author"><span class="firstname">Bjarne</span> <span class="surname">Stroustrup</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley, Inc.. </span><span class="pagenums">Appendix D. </span><span class="publisher"><span class="publishername">
Addison Wesley
. </span></span></p></div><div class="biblioentry"><a id="id428016"></a><p><span class="title"><i>
Standard C++ IOStreams and Locales
</i>. </span><span class="subtitle">
Advanced Programmer's Guide and Reference
. </span><span class="author"><span class="firstname">Angelika</span> <span class="surname">Langer</span>. </span><span class="author"><span class="firstname">Klaus</span> <span class="surname">Kreft</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley Longman, Inc.. </span><span class="publisher"><span class="publishername">
Addison Wesley Longman
. </span></span></p></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt06ch14.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="localization.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="codecvt.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 14. Locales </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> codecvt</td></tr></table></div></body></html>

37
libstdc++-v3/doc/html/manual/bk01pt07ch16.html Normal file
View File

@ -0,0 +1,37 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 16. Sequences</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="containers.html" title="Part VII. Containers" /><link rel="prev" href="containers.html" title="Part VII. Containers" /><link rel="next" href="bk01pt07ch16s02.html" title="vector" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 16. Sequences</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="containers.html">Prev</a> </td><th width="60%" align="center">Part VII. Containers</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt07ch16s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.containers.sequences"></a>Chapter 16. Sequences</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt07ch16.html#containers.sequences.list">list</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt07ch16.html#sequences.list.size">list::size() is O(n)</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt07ch16s02.html">vector</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt07ch16s02.html#sequences.vector.management">Space Overhead Management</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="containers.sequences.list"></a>list</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="sequences.list.size"></a>list::size() is O(n)</h3></div></div></div><p>
Yes it is, and that's okay. This is a decision that we preserved
when we imported SGI's STL implementation. The following is
quoted from <a class="ulink" href="http://www.sgi.com/tech/stl/FAQ.html" target="_top">their FAQ</a>:
</p><div class="blockquote"><blockquote class="blockquote"><p>
The size() member function, for list and slist, takes time
proportional to the number of elements in the list. This was a
deliberate tradeoff. The only way to get a constant-time
size() for linked lists would be to maintain an extra member
variable containing the list's size. This would require taking
extra time to update that variable (it would make splice() a
linear time operation, for example), and it would also make the
list larger. Many list algorithms don't require that extra
word (algorithms that do require it might do better with
vectors than with lists), and, when it is necessary to maintain
an explicit size count, it's something that users can do
themselves.
</p><p>
This choice is permitted by the C++ standard. The standard says
that size() “<span class="quote">should</span>” be constant time, and
“<span class="quote">should</span>” does not mean the same thing as
“<span class="quote">shall</span>”. This is the officially recommended ISO
wording for saying that an implementation is supposed to do
something unless there is a good reason not to.
</p><p>
One implication of linear time size(): you should never write
</p><pre class="programlisting">
if (L.size() == 0)
...
</pre><p>
Instead, you should write
</p><pre class="programlisting">
if (L.empty())
...
</pre></blockquote></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="containers.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="containers.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt07ch16s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part VII. Containers </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> vector</td></tr></table></div></body></html>

16
libstdc++-v3/doc/html/manual/bk01pt07ch16s02.html Normal file
View File

@ -0,0 +1,16 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>vector</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt07ch16.html" title="Chapter 16. Sequences" /><link rel="prev" href="bk01pt07ch16.html" title="Chapter 16. Sequences" /><link rel="next" href="bk01pt07ch17.html" title="Chapter 17. Associative" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">vector</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt07ch16.html">Prev</a> </td><th width="60%" align="center">Chapter 16. Sequences</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt07ch17.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="containers.sequences.vector"></a>vector</h2></div></div></div><p>
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="sequences.vector.management"></a>Space Overhead Management</h3></div></div></div><p>
In <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-04/msg00105.html" target="_top">this
message to the list</a>, Daniel Kostecky announced work on an
alternate form of <code class="code">std::vector</code> that would support
hints on the number of elements to be over-allocated. The design
was also described, along with possible implementation choices.
</p><p>
The first two alpha releases were announced <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-07/msg00048.html" target="_top">here</a>
and <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-07/msg00111.html" target="_top">here</a>.
The releases themselves are available at
<a class="ulink" href="http://www.kotelna.sk/dk/sw/caphint/" target="_top">
http://www.kotelna.sk/dk/sw/caphint/</a>.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt07ch16.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt07ch16.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt07ch17.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 16. Sequences </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 17. Associative</td></tr></table></div></body></html>

84
libstdc++-v3/doc/html/manual/bk01pt07ch17.html Normal file
View File

@ -0,0 +1,84 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 17. Associative</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="containers.html" title="Part VII. Containers" /><link rel="prev" href="bk01pt07ch16s02.html" title="vector" /><link rel="next" href="bk01pt07ch17s02.html" title="bitset" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 17. Associative</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt07ch16s02.html">Prev</a> </td><th width="60%" align="center">Part VII. Containers</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt07ch17s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.containers.associative"></a>Chapter 17. Associative</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt07ch17.html#containers.associative.insert_hints">Insertion Hints</a></span></dt><dt><span class="sect1"><a href="bk01pt07ch17s02.html">bitset</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt07ch17s02.html#associative.bitset.size_variable">Size Variable</a></span></dt><dt><span class="sect2"><a href="bk01pt07ch17s02.html#associative.bitset.type_string">Type String</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="containers.associative.insert_hints"></a>Insertion Hints</h2></div></div></div><p>
Section [23.1.2], Table 69, of the C++ standard lists this
function for all of the associative containers (map, set, etc):
</p><pre class="programlisting">
a.insert(p,t);
</pre><p>
where 'p' is an iterator into the container 'a', and 't' is the
item to insert. The standard says that “<span class="quote"><code class="code">t</code> is
inserted as close as possible to the position just prior to
<code class="code">p</code>.</span>” (Library DR #233 addresses this topic,
referring to <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html" target="_top">N1780</a>.
Since version 4.2 GCC implements the resolution to DR 233, so
that insertions happen as close as possible to the hint. For
earlier releases the hint was only used as described below.
</p><p>
Here we'll describe how the hinting works in the libstdc++
implementation, and what you need to do in order to take
advantage of it. (Insertions can change from logarithmic
complexity to amortized constant time, if the hint is properly
used.) Also, since the current implementation is based on the
SGI STL one, these points may hold true for other library
implementations also, since the HP/SGI code is used in a lot of
places.
</p><p>
In the following text, the phrases <span class="emphasis"><em>greater
than</em></span> and <span class="emphasis"><em>less than</em></span> refer to the
results of the strict weak ordering imposed on the container by
its comparison object, which defaults to (basically)
“<span class="quote">&lt;</span>”. Using those phrases is semantically sloppy,
but I didn't want to get bogged down in syntax. I assume that if
you are intelligent enough to use your own comparison objects,
you are also intelligent enough to assign “<span class="quote">greater</span>”
and “<span class="quote">lesser</span>” their new meanings in the next
paragraph. *grin*
</p><p>
If the <code class="code">hint</code> parameter ('p' above) is equivalent to:
</p><div class="itemizedlist"><ul type="disc"><li><p>
<code class="code">begin()</code>, then the item being inserted should
have a key less than all the other keys in the container.
The item will be inserted at the beginning of the container,
becoming the new entry at <code class="code">begin()</code>.
</p></li><li><p>
<code class="code">end()</code>, then the item being inserted should have
a key greater than all the other keys in the container. The
item will be inserted at the end of the container, becoming
the new entry at <code class="code">end()</code>.
</p></li><li><p>
neither <code class="code">begin()</code> nor <code class="code">end()</code>, then:
Let <code class="code">h</code> be the entry in the container pointed to
by <code class="code">hint</code>, that is, <code class="code">h = *hint</code>. Then
the item being inserted should have a key less than that of
<code class="code">h</code>, and greater than that of the item preceding
<code class="code">h</code>. The new item will be inserted between
<code class="code">h</code> and <code class="code">h</code>'s predecessor.
</p></li></ul></div><p>
For <code class="code">multimap</code> and <code class="code">multiset</code>, the
restrictions are slightly looser: “<span class="quote">greater than</span>”
should be replaced by “<span class="quote">not less than</span>”and “<span class="quote">less
than</span>” should be replaced by “<span class="quote">not greater
than.</span>” (Why not replace greater with
greater-than-or-equal-to? You probably could in your head, but
the mathematicians will tell you that it isn't the same thing.)
</p><p>
If the conditions are not met, then the hint is not used, and the
insertion proceeds as if you had called <code class="code"> a.insert(t)
</code> instead. (<span class="emphasis"><em>Note </em></span> that GCC releases
prior to 3.0.2 had a bug in the case with <code class="code">hint ==
begin()</code> for the <code class="code">map</code> and <code class="code">set</code>
classes. You should not use a hint argument in those releases.)
</p><p>
This behavior goes well with other containers'
<code class="code">insert()</code> functions which take an iterator: if used,
the new item will be inserted before the iterator passed as an
argument, same as the other containers.
</p><p>
<span class="emphasis"><em>Note </em></span> also that the hint in this
implementation is a one-shot. The older insertion-with-hint
routines check the immediately surrounding entries to ensure that
the new item would in fact belong there. If the hint does not
point to the correct place, then no further local searching is
done; the search begins from scratch in logarithmic time.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt07ch16s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="containers.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt07ch17s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">vector </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> bitset</td></tr></table></div></body></html>

105
libstdc++-v3/doc/html/manual/bk01pt07ch17s02.html Normal file
View File

@ -0,0 +1,105 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>bitset</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt07ch17.html" title="Chapter 17. Associative" /><link rel="prev" href="bk01pt07ch17.html" title="Chapter 17. Associative" /><link rel="next" href="bk01pt07ch18.html" title="Chapter 18. Interacting with C" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">bitset</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt07ch17.html">Prev</a> </td><th width="60%" align="center">Chapter 17. Associative</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt07ch18.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="containers.associative.bitset"></a>bitset</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="associative.bitset.size_variable"></a>Size Variable</h3></div></div></div><p>
No, you cannot write code of the form
</p><pre class="programlisting">
#include &lt;bitset&gt;
void foo (size_t n)
{
std::bitset&lt;n&gt; bits;
....
}
</pre><p>
because <code class="code">n</code> must be known at compile time. Your
compiler is correct; it is not a bug. That's the way templates
work. (Yes, it <span class="emphasis"><em>is</em></span> a feature.)
</p><p>
There are a couple of ways to handle this kind of thing. Please
consider all of them before passing judgement. They include, in
no particular order:
</p><div class="itemizedlist"><ul type="disc"><li><p>A very large N in <code class="code">bitset&lt;N&gt;</code>.</p></li><li><p>A container&lt;bool&gt;.</p></li><li><p>Extremely weird solutions.</p></li></ul></div><p>
<span class="emphasis"><em>A very large N in
<code class="code">bitset&lt;N&gt;</code>.  </em></span> It has been
pointed out a few times in newsgroups that N bits only takes up
(N/8) bytes on most systems, and division by a factor of eight is
pretty impressive when speaking of memory. Half a megabyte given
over to a bitset (recall that there is zero space overhead for
housekeeping info; it is known at compile time exactly how large
the set is) will hold over four million bits. If you're using
those bits as status flags (e.g.,
“<span class="quote">changed</span>”/“<span class="quote">unchanged</span>” flags), that's a
<span class="emphasis"><em>lot</em></span> of state.
</p><p>
You can then keep track of the “<span class="quote">maximum bit used</span>”
during some testing runs on representative data, make note of how
many of those bits really need to be there, and then reduce N to
a smaller number. Leave some extra space, of course. (If you
plan to write code like the incorrect example above, where the
bitset is a local variable, then you may have to talk your
compiler into allowing that much stack space; there may be zero
space overhead, but it's all allocated inside the object.)
</p><p>
<span class="emphasis"><em>A container&lt;bool&gt;.  </em></span> 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 class="code">Container&lt;char&gt;</code> or
<code class="code">Container&lt;short int&gt;</code>. Specifically,
<code class="code">vector&lt;bool&gt;</code> is required to be specialized for
that space savings.
</p><p>
The problem is that <code class="code">vector&lt;bool&gt;</code> doesn't
behave like a normal vector anymore. There have been recent
journal articles which discuss the problems (the ones by Herb
Sutter in the May and July/August 1999 issues of C++ Report cover
it well). Future revisions of the ISO C++ Standard will change
the requirement for <code class="code">vector&lt;bool&gt;</code>
specialization. In the meantime, <code class="code">deque&lt;bool&gt;</code>
is recommended (although its behavior is sane, you probably will
not get the space savings, but the allocation scheme is different
than that of vector).
</p><p>
<span class="emphasis"><em>Extremely weird solutions.  </em></span> 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 class="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 Independent Code, then open the newly-created object
file and load those wrapper functions. You'll have an
instantiation of <code class="code">bitset&lt;N&gt;</code> for the exact
<code class="code">N</code> that you need at the time. Don't forget to delete
the temporary files. (Yes, this <span class="emphasis"><em>can</em></span> be, and
<span class="emphasis"><em>has been</em></span>, done.)
</p><p>
This would be the approach of either a visionary genius or a
raving lunatic, depending on your programming and management
style. Probably the latter.
</p><p>
Which of the above techniques you use, if any, are up to you and
your intended application. Some time/space profiling is
indicated if it really matters (don't just guess). And, if you
manage to do anything 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++ has
<a class="ulink" href="../ext/sgiexts.html#ch23" target="_top">some extensions</a>.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="associative.bitset.type_string"></a>Type String</h3></div></div></div><p>
</p><p>
Bitmasks do not take char* nor const char* arguments in their
constructors. This is something of an accident, but you can read
about the problem: follow the library's “<span class="quote">Links</span>” from
the homepage, and from the C++ information “<span class="quote">defect
reflector</span>” link, select the library issues list. Issue
number 116 describes the problem.
</p><p>
For now you can simply make a temporary string object using the
constructor expression:
</p><pre class="programlisting">
std::bitset&lt;5&gt; b ( std::string(“<span class="quote">10110</span>”) );
</pre><p>
instead of
</p><pre class="programlisting">
std::bitset&lt;5&gt; b ( “<span class="quote">10110</span>” ); // invalid
</pre></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt07ch17.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt07ch17.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt07ch18.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 17. Associative </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 18. Interacting with C</td></tr></table></div></body></html>

60
libstdc++-v3/doc/html/manual/bk01pt07ch18.html Normal file
View File

@ -0,0 +1,60 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 18. Interacting with C</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="containers.html" title="Part VII. Containers" /><link rel="prev" href="bk01pt07ch17s02.html" title="bitset" /><link rel="next" href="iterators.html" title="Part VIII. Iterators" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 18. Interacting with C</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt07ch17s02.html">Prev</a> </td><th width="60%" align="center">Part VII. Containers</th><td width="20%" align="right"> <a accesskey="n" href="iterators.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.containers.c"></a>Chapter 18. Interacting with C</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt07ch18.html#containers.c.vs_array">Containers vs. Arrays</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="containers.c.vs_array"></a>Containers vs. Arrays</h2></div></div></div><p>
You're writing some code and can't decide whether to use builtin
arrays or some kind of container. There are compelling reasons
to use one of the container classes, but you're afraid that
you'll eventually run into difficulties, change everything back
to arrays, and then have to change all the code that uses those
data types to keep up with the change.
</p><p>
If your code makes use of the standard algorithms, this isn't as
scary as it sounds. The algorithms don't know, nor care, about
the kind of “<span class="quote">container</span>” on which they work, since
the algorithms are only given endpoints to work with. For the
container classes, these are iterators (usually
<code class="code">begin()</code> and <code class="code">end()</code>, but not always).
For builtin arrays, these are the address of the first element
and the <a class="ulink" href="../24_iterators/howto.html#2" target="_top">past-the-end</a> element.
</p><p>
Some very simple wrapper functions can hide all of that from the
rest of the code. For example, a pair of functions called
<code class="code">beginof</code> can be written, one that takes an array,
another that takes a vector. The first returns a pointer to the
first element, and the second returns the vector's
<code class="code">begin()</code> iterator.
</p><p>
The functions should be made template functions, and should also
be declared inline. As pointed out in the comments in the code
below, this can lead to <code class="code">beginof</code> being optimized out
of existence, so you pay absolutely nothing in terms of increased
code size or execution time.
</p><p>
The result is that if all your algorithm calls look like
</p><pre class="programlisting">
std::transform(beginof(foo), endof(foo), beginof(foo), SomeFunction);
</pre><p>
then the type of foo can change from an array of ints to a vector
of ints to a deque of ints and back again, without ever changing
any client code.
</p><p>
This author has a collection of such functions, called
“<span class="quote">*of</span>” because they all extend the builtin
“<span class="quote">sizeof</span>”. It started with some Usenet discussions
on a transparent way to find the length of an array. A
simplified and much-reduced version for easier reading is <a class="ulink" href="wrappers_h.txt" target="_top">given here</a>.
</p><p>
Astute readers will notice two things at once: first, that the
container class is still a <code class="code">vector&lt;T&gt;</code> instead
of a more general <code class="code">Container&lt;T&gt;</code>. This would
mean that three functions for <code class="code">deque</code> would have to be
added, another three for <code class="code">list</code>, and so on. This is
due to problems with getting template resolution correct; I find
it easier just to give the extra three lines and avoid confusion.
</p><p>
Second, the line
</p><pre class="programlisting">
inline unsigned int lengthof (T (&amp;)[sz]) { return sz; }
</pre><p>
looks just weird! Hint: unused parameters can be left nameless.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt07ch17s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="containers.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="iterators.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">bitset </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part VIII. Iterators</td></tr></table></div></body></html>

30
libstdc++-v3/doc/html/manual/bk01pt08ch19.html Normal file
View File

@ -0,0 +1,30 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 19. Predefined</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="iterators.html" title="Part VIII. Iterators" /><link rel="prev" href="iterators.html" title="Part VIII. Iterators" /><link rel="next" href="bk01pt08ch19s02.html" title="One Past the End" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 19. Predefined</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="iterators.html">Prev</a> </td><th width="60%" align="center">Part VIII. Iterators</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt08ch19s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.iterators.predefined"></a>Chapter 19. Predefined</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt08ch19.html#iterators.predefined.vs_pointers">Iterators vs. Pointers</a></span></dt><dt><span class="sect1"><a href="bk01pt08ch19s02.html">One Past the End</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="iterators.predefined.vs_pointers"></a>Iterators vs. Pointers</h2></div></div></div><p><a class="ulink" href="../faq/index.html#5_1" target="_top">FAQ 5.1</a> points out that iterators
are not implemented as pointers. They are a generalization of
pointers, but they are implemented in libstdc++ as separate classes.
</p><p>Keeping that simple fact in mind as you design your code will
prevent a whole lot of difficult-to-understand bugs.
</p><p>You can think of it the other way 'round, even. Since iterators
are a generalization, that means that <span class="emphasis"><em>pointers</em></span> are
<span class="emphasis"><em>iterators</em></span>, and that pointers can be used whenever an
iterator would be. All those functions in the Algorithms chapter
of the Standard will work just as well on plain arrays and their
pointers.
</p><p>That doesn't mean that when you pass in a pointer, it gets wrapped
into some special delegating iterator-to-pointer class with a layer
of overhead. (If you think that's the case anywhere, you don't
understand templates to begin with...) Oh, no; if you pass
in a pointer, then the compiler will instantiate that template
using T* as a type, and good old high-speed pointer arithmetic as
its operations, so the resulting code will be doing exactly the same
things as it would be doing if you had hand-coded it yourself (for
the 273rd time).
</p><p>How much overhead <span class="emphasis"><em>is</em></span> there when using an iterator class?
Very little. Most of the layering classes contain nothing but
typedefs, and typedefs are "meta-information" that simply
tell the compiler some nicknames; they don't create code. That
information gets passed down through inheritance, so while the
compiler has to do work looking up all the names, your runtime code
does not. (This has been a prime concern from the beginning.)
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="iterators.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="iterators.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt08ch19s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part VIII. Iterators </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> One Past the End</td></tr></table></div></body></html>

83
libstdc++-v3/doc/html/manual/bk01pt08ch19s02.html Normal file
View File

@ -0,0 +1,83 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>One Past the End</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt08ch19.html" title="Chapter 19. Predefined" /><link rel="prev" href="bk01pt08ch19.html" title="Chapter 19. Predefined" /><link rel="next" href="algorithms.html" title="Part IX. Algorithms" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">One Past the End</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt08ch19.html">Prev</a> </td><th width="60%" align="center">Chapter 19. Predefined</th><td width="20%" align="right"> <a accesskey="n" href="algorithms.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="iterators.predefined.end"></a>One Past the End</h2></div></div></div><p>This starts off sounding complicated, but is actually very easy,
especially towards the end. Trust me.
</p><p>Beginners usually have a little trouble understand the whole
'past-the-end' thing, until they remember their early algebra classes
(see, they <span class="emphasis"><em>told</em></span> you that stuff would come in handy!) and
the concept of half-open ranges.
</p><p>First, some history, and a reminder of some of the funkier rules in
C and C++ for builtin arrays. The following rules have always been
true for both languages:
</p><div class="orderedlist"><ol type="1"><li><p>You can point anywhere in the array, <span class="emphasis"><em>or to the first element
past the end of the array</em></span>. A pointer that points to one
past the end of the array is guaranteed to be as unique as a
pointer to somewhere inside the array, so that you can compare
such pointers safely.
</p></li><li><p>You can only dereference a pointer that points into an array.
If your array pointer points outside the array -- even to just
one past the end -- and you dereference it, Bad Things happen.
</p></li><li><p>Strictly speaking, simply pointing anywhere else invokes
undefined behavior. Most programs won't puke until such a
pointer is actually dereferenced, but the standards leave that
up to the platform.
</p></li></ol></div><p>The reason this past-the-end addressing was allowed is to make it
easy to write a loop to go over an entire array, e.g.,
while (*d++ = *s++);.
</p><p>So, when you think of two pointers delimiting an array, don't think
of them as indexing 0 through n-1. Think of them as <span class="emphasis"><em>boundary
markers</em></span>:
</p><pre class="programlisting">
beginning end
| |
| | This is bad. Always having to
| | remember to add or subtract one.
| | Off-by-one bugs very common here.
V V
array of N elements
|---|---|--...--|---|---|
| 0 | 1 | ... |N-2|N-1|
|---|---|--...--|---|---|
^ ^
| |
| | This is good. This is safe. This
| | is guaranteed to work. Just don't
| | dereference 'end'.
beginning end
</pre><p>See? Everything between the boundary markers is part of the array.
Simple.
</p><p>Now think back to your junior-high school algebra course, when you
were learning how to draw graphs. Remember that a graph terminating
with a solid dot meant, "Everything up through this point,"
and a graph terminating with an open dot meant, "Everything up
to, but not including, this point," respectively called closed
and open ranges? Remember how closed ranges were written with
brackets, <span class="emphasis"><em>[a,b]</em></span>, and open ranges were written with parentheses,
<span class="emphasis"><em>(a,b)</em></span>?
</p><p>The boundary markers for arrays describe a <span class="emphasis"><em>half-open range</em></span>,
starting with (and including) the first element, and ending with (but
not including) the last element: <span class="emphasis"><em>[beginning,end)</em></span>. See, I
told you it would be simple in the end.
</p><p>Iterators, and everything working with iterators, follows this same
time-honored tradition. A container's <code class="code">begin()</code> method returns
an iterator referring to the first element, and its <code class="code">end()</code>
method returns a past-the-end iterator, which is guaranteed to be
unique and comparable against any other iterator pointing into the
middle of the container.
</p><p>Container constructors, container methods, and algorithms, all take
pairs of iterators describing a range of values on which to operate.
All of these ranges are half-open ranges, so you pass the beginning
iterator as the starting parameter, and the one-past-the-end iterator
as the finishing parameter.
</p><p>This generalizes very well. You can operate on sub-ranges quite
easily this way; functions accepting a <span class="emphasis"><em>[first,last)</em></span> range
don't know or care whether they are the boundaries of an entire {array,
sequence, container, whatever}, or whether they only enclose a few
elements from the center. This approach also makes zero-length
sequences very simple to recognize: if the two endpoints compare
equal, then the {array, sequence, container, whatever} is empty.
</p><p>Just don't dereference <code class="code">end()</code>.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt08ch19.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt08ch19.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="algorithms.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 19. Predefined </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part IX. Algorithms</td></tr></table></div></body></html>

13
libstdc++-v3/doc/html/manual/bk01pt09ch20.html Normal file
View File

@ -0,0 +1,13 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 20. Mutating</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; , &#10; algorithm&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="algorithms.html" title="Part IX. Algorithms" /><link rel="prev" href="bk01pt09pr02.html" title="" /><link rel="next" href="numerics.html" title="Part X. Numerics" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 20. Mutating</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt09pr02.html">Prev</a> </td><th width="60%" align="center">Part IX. Algorithms</th><td width="20%" align="right"> <a accesskey="n" href="numerics.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.algorithms.mutating"></a>Chapter 20. Mutating</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt09ch20.html#algorithms.mutating.swap"><code class="function">swap</code></a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt09ch20.html#algorithms.swap.specializations">Specializations</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="algorithms.mutating.swap"></a><code class="function">swap</code></h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="algorithms.swap.specializations"></a>Specializations</h3></div></div></div><p>If you call <code class="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 class="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></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt09pr02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="algorithms.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="numerics.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part X. Numerics</td></tr></table></div></body></html>

35
libstdc++-v3/doc/html/manual/bk01pt09pr02.html Normal file
View File

@ -0,0 +1,35 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; , &#10; algorithm&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="algorithms.html" title="Part IX. Algorithms" /><link rel="prev" href="algorithms.html" title="Part IX. Algorithms" /><link rel="next" href="bk01pt09ch20.html" title="Chapter 20. Mutating" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="algorithms.html">Prev</a> </td><th width="60%" align="center">Part IX. Algorithms</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt09ch20.html">Next</a></td></tr></table><hr /></div><div class="preface" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="id405802"></a></h2></div></div></div><p>
The neatest accomplishment of the algorithms chapter is that all the
work is done via iterators, not containers directly. This means two
important things:
</p><div class="orderedlist"><ol type="1"><li><p>
Anything that behaves like an iterator can be used in one of
these algorithms. Raw pointers make great candidates, thus
built-in arrays are fine containers, as well as your own iterators.
</p></li><li><p>
The algorithms do not (and cannot) affect the container as a
whole; only the things between the two iterator endpoints. If
you pass a range of iterators only enclosing the middle third of
a container, then anything outside that range is inviolate.
</p></li></ol></div><p>
Even strings can be fed through the algorithms here, although the
string class has specialized versions of many of these functions
(for example, <code class="code">string::find()</code>). Most of the examples
on this page will use simple arrays of integers as a playground
for algorithms, just to keep things simple. The use of
<span class="emphasis"><em>N</em></span> as a size in the examples is to keep
things easy to read but probably won't be valid code. You can
use wrappers such as those described in the <a class="ulink" href="../23_containers/howto.html" target="_top">containers chapter</a> to
keep real code readable.
</p><p>
The single thing that trips people up the most is the definition
of <span class="emphasis"><em>range</em></span> used with iterators; the famous
"past-the-end" rule that everybody loves to hate. The
<a class="ulink" href="../24_iterators/howto.html#2" target="_top">iterators
chapter</a> of this document has a complete explanation of
this simple rule that seems to cause so much confusion. Once you
get <span class="emphasis"><em>range</em></span> into your head (it's not that
hard, honest!), then the algorithms are a cakewalk.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="algorithms.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="algorithms.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt09ch20.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part IX. Algorithms </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 20. Mutating</td></tr></table></div></body></html>

19
libstdc++-v3/doc/html/manual/bk01pt10ch21.html Normal file
View File

@ -0,0 +1,19 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 21. Complex</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="numerics.html" title="Part X. Numerics" /><link rel="prev" href="numerics.html" title="Part X. Numerics" /><link rel="next" href="bk01pt10ch22.html" title="Chapter 22. Generalized Operations" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 21. Complex</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="numerics.html">Prev</a> </td><th width="60%" align="center">Part X. Numerics</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt10ch22.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.numerics.complex"></a>Chapter 21. Complex</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt10ch21.html#numerics.complex.processing">complex Processing</a></span></dt></dl></div><p>
</p><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="numerics.complex.processing"></a>complex Processing</h2></div></div></div><p>
</p><p>Using <code class="code">complex&lt;&gt;</code> becomes even more comple- er, sorry,
<span class="emphasis"><em>complicated</em></span>, with the not-quite-gratuitously-incompatible
addition of complex types to the C language. David Tribble has
compiled a list of C++98 and C99 conflict points; his description of
C's new type versus those of C++ and how to get them playing together
nicely is
<a class="ulink" href="http://david.tribble.com/text/cdiffs.htm#C99-complex" target="_top">here</a>.
</p><p><code class="code">complex&lt;&gt;</code> is intended to be instantiated with a
floating-point type. As long as you meet that and some other basic
requirements, then the resulting instantiation has all of the usual
math operators defined, as well as definitions of <code class="code">op&lt;&lt;</code>
and <code class="code">op&gt;&gt;</code> that work with iostreams: <code class="code">op&lt;&lt;</code>
prints <code class="code">(u,v)</code> and <code class="code">op&gt;&gt;</code> can read <code class="code">u</code>,
<code class="code">(u)</code>, and <code class="code">(u,v)</code>.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="numerics.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="numerics.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt10ch22.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part X. Numerics </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 22. Generalized Operations</td></tr></table></div></body></html>

26
libstdc++-v3/doc/html/manual/bk01pt10ch22.html Normal file
View File

@ -0,0 +1,26 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 22. Generalized Operations</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="numerics.html" title="Part X. Numerics" /><link rel="prev" href="bk01pt10ch21.html" title="Chapter 21. Complex" /><link rel="next" href="bk01pt10ch23.html" title="Chapter 23. Interacting with C" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 22. Generalized Operations</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt10ch21.html">Prev</a> </td><th width="60%" align="center">Part X. Numerics</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt10ch23.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.numerics.generalized_ops"></a>Chapter 22. Generalized Operations</h2></div></div></div><p>
</p><p>There are four generalized functions in the &lt;numeric&gt; header
that follow the same conventions as those in &lt;algorithm&gt;. Each
of them is overloaded: one signature for common default operations,
and a second for fully general operations. Their names are
self-explanatory to anyone who works with numerics on a regular basis:
</p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">accumulate</code></p></li><li><p><code class="code">inner_product</code></p></li><li><p><code class="code">partial_sum</code></p></li><li><p><code class="code">adjacent_difference</code></p></li></ul></div><p>Here is a simple example of the two forms of <code class="code">accumulate</code>.
</p><pre class="programlisting">
int ar[50];
int someval = somefunction();
// ...initialize members of ar to something...
int sum = std::accumulate(ar,ar+50,0);
int sum_stuff = std::accumulate(ar,ar+50,someval);
int product = std::accumulate(ar,ar+50,1,std::multiplies&lt;int&gt;());
</pre><p>The first call adds all the members of the array, using zero as an
initial value for <code class="code">sum</code>. The second does the same, but uses
<code class="code">someval</code> as the starting value (thus, <code class="code">sum_stuff == sum +
someval</code>). The final call uses the second of the two signatures,
and multiplies all the members of the array; here we must obviously
use 1 as a starting value instead of 0.
</p><p>The other three functions have similar dual-signature forms.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt10ch21.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="numerics.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt10ch23.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 21. Complex </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 23. Interacting with C</td></tr></table></div></body></html>

18
libstdc++-v3/doc/html/manual/bk01pt10ch23.html Normal file
View File

@ -0,0 +1,18 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 23. Interacting with C</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="numerics.html" title="Part X. Numerics" /><link rel="prev" href="bk01pt10ch22.html" title="Chapter 22. Generalized Operations" /><link rel="next" href="bk01pt10ch23s02.html" title="C99" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 23. Interacting with C</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt10ch22.html">Prev</a> </td><th width="60%" align="center">Part X. Numerics</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt10ch23s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.numerics.c"></a>Chapter 23. Interacting with C</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt10ch23.html#numerics.c.array">Numerics vs. Arrays</a></span></dt><dt><span class="sect1"><a href="bk01pt10ch23s02.html">C99</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="numerics.c.array"></a>Numerics vs. Arrays</h2></div></div></div><p>One of the major reasons why FORTRAN can chew through numbers so well
is that it is defined to be free of pointer aliasing, an assumption
that C89 is not allowed to make, and neither is C++98. C99 adds a new
keyword, <code class="code">restrict</code>, to apply to individual pointers. The
C++ solution is contained in the library rather than the language
(although many vendors can be expected to add this to their compilers
as an extension).
</p><p>That library solution is a set of two classes, five template classes,
and "a whole bunch" of functions. The classes are required
to be free of pointer aliasing, so compilers can optimize the
daylights out of them the same way that they have been for FORTRAN.
They are collectively called <code class="code">valarray</code>, although strictly
speaking this is only one of the five template classes, and they are
designed to be familiar to people who have worked with the BLAS
libraries before.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt10ch22.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="numerics.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt10ch23s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 22. Generalized Operations </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> C99</td></tr></table></div></body></html>

16
libstdc++-v3/doc/html/manual/bk01pt10ch23s02.html Normal file
View File

@ -0,0 +1,16 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>C99</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt10ch23.html" title="Chapter 23. Interacting with C" /><link rel="prev" href="bk01pt10ch23.html" title="Chapter 23. Interacting with C" /><link rel="next" href="io.html" title="Part XI. Input and Output" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">C99</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt10ch23.html">Prev</a> </td><th width="60%" align="center">Chapter 23. Interacting with C</th><td width="20%" align="right"> <a accesskey="n" href="io.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="numerics.c.c99"></a>C99</h2></div></div></div><p>In addition to the other topics on this page, we'll note here some
of the C99 features that appear in libstdc++.
</p><p>The C99 features depend on the <code class="code">--enable-c99</code> configure flag.
This flag is already on by default, but it can be disabled by the
user. Also, the configuration machinery will disable it if the
necessary support for C99 (e.g., header files) cannot be found.
</p><p>As of GCC 3.0, C99 support includes classification functions
such as <code class="code">isnormal</code>, <code class="code">isgreater</code>,
<code class="code">isnan</code>, etc.
The functions used for 'long long' support such as <code class="code">strtoll</code>
are supported, as is the <code class="code">lldiv_t</code> typedef. Also supported
are the wide character functions using 'long long', like
<code class="code">wcstoll</code>.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt10ch23.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt10ch23.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="io.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 23. Interacting with C </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part XI. Input and Output</td></tr></table></div></body></html>

113
libstdc++-v3/doc/html/manual/bk01pt11ch24.html Normal file
View File

@ -0,0 +1,113 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 24. Iostream Objects</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="io.html" title="Part XI. Input and Output" /><link rel="prev" href="io.html" title="Part XI. Input and Output" /><link rel="next" href="bk01pt11ch25.html" title="Chapter 25. Stream Buffers" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 24. Iostream Objects</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="io.html">Prev</a> </td><th width="60%" align="center">Part XI. Input and Output</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt11ch25.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.io.objects"></a>Chapter 24. Iostream Objects</h2></div></div></div><p>To minimize the time you have to wait on the compiler, it's good to
only include the headers you really need. Many people simply include
&lt;iostream&gt; when they don't need to -- and that can <span class="emphasis"><em>penalize
your runtime as well.</em></span> Here are some tips on which header to use
for which situations, starting with the simplest.
</p><p><span class="emphasis"><em>&lt;iosfwd&gt;</em></span> should be included whenever you simply
need the <span class="emphasis"><em>name</em></span> of an I/O-related class, such as
"ofstream" or "basic_streambuf". Like the name
implies, these are forward declarations. (A word to all you fellow
old school programmers: trying to forward declare classes like
"class istream;" won't work. Look in the iosfwd header if
you'd like to know why.) For example,
</p><pre class="programlisting">
#include &lt;iosfwd&gt;
class MyClass
{
....
std::ifstream&amp; input_file;
};
extern std::ostream&amp; operator&lt;&lt; (std::ostream&amp;, MyClass&amp;);
</pre><p><span class="emphasis"><em>&lt;ios&gt;</em></span> declares the base classes for the entire
I/O stream hierarchy, std::ios_base and std::basic_ios&lt;charT&gt;, the
counting types std::streamoff and std::streamsize, the file
positioning type std::fpos, and the various manipulators like
std::hex, std::fixed, std::noshowbase, and so forth.
</p><p>The ios_base class is what holds the format flags, the state flags,
and the functions which change them (setf(), width(), precision(),
etc). You can also store extra data and register callback functions
through ios_base, but that has been historically underused. Anything
which doesn't depend on the type of characters stored is consolidated
here.
</p><p>The template class basic_ios is the highest template class in the
hierarchy; it is the first one depending on the character type, and
holds all general state associated with that type: the pointer to the
polymorphic stream buffer, the facet information, etc.
</p><p><span class="emphasis"><em>&lt;streambuf&gt;</em></span> declares the template class
basic_streambuf, and two standard instantiations, streambuf and
wstreambuf. If you need to work with the vastly useful and capable
stream buffer classes, e.g., to create a new form of storage
transport, this header is the one to include.
</p><p><span class="emphasis"><em>&lt;istream&gt;</em></span>/<span class="emphasis"><em>&lt;ostream&gt;</em></span> are
the headers to include when you are using the &gt;&gt;/&lt;&lt;
interface, or any of the other abstract stream formatting functions.
For example,
</p><pre class="programlisting">
#include &lt;istream&gt;
std::ostream&amp; operator&lt;&lt; (std::ostream&amp; os, MyClass&amp; c)
{
return os &lt;&lt; c.data1() &lt;&lt; c.data2();
}
</pre><p>The std::istream and std::ostream classes are the abstract parents of
the various concrete implementations. If you are only using the
interfaces, then you only need to use the appropriate interface header.
</p><p><span class="emphasis"><em>&lt;iomanip&gt;</em></span> provides "extractors and inserters
that alter information maintained by class ios_base and its derived
classes," such as std::setprecision and std::setw. If you need
to write expressions like <code class="code">os &lt;&lt; setw(3);</code> or
<code class="code">is &gt;&gt; setbase(8);</code>, you must include &lt;iomanip&gt;.
</p><p><span class="emphasis"><em>&lt;sstream&gt;</em></span>/<span class="emphasis"><em>&lt;fstream&gt;</em></span>
declare the six stringstream and fstream classes. As they are the
standard concrete descendants of istream and ostream, you will already
know about them.
</p><p>Finally, <span class="emphasis"><em>&lt;iostream&gt;</em></span> provides the eight standard
global objects (cin, cout, etc). To do this correctly, this header
also provides the contents of the &lt;istream&gt; and &lt;ostream&gt;
headers, but nothing else. The contents of this header look like
</p><pre class="programlisting">
#include &lt;ostream&gt;
#include &lt;istream&gt;
namespace std
{
extern istream cin;
extern ostream cout;
....
// this is explained below
<span class="emphasis"><em>static ios_base::Init __foo;</em></span> // not its real name
}
</pre><p>Now, the runtime penalty mentioned previously: the global objects
must be initialized before any of your own code uses them; this is
guaranteed by the standard. Like any other global object, they must
be initialized once and only once. This is typically done with a
construct like the one above, and the nested class ios_base::Init is
specified in the standard for just this reason.
</p><p>How does it work? Because the header is included before any of your
code, the <span class="emphasis"><em>__foo</em></span> object is constructed before any of
your objects. (Global objects are built in the order in which they
are declared, and destroyed in reverse order.) The first time the
constructor runs, the eight stream objects are set up.
</p><p>The <code class="code">static</code> keyword means that each object file compiled
from a source file containing &lt;iostream&gt; will have its own
private copy of <span class="emphasis"><em>__foo</em></span>. There is no specified order
of construction across object files (it's one of those pesky NP
problems that make life so interesting), so one copy in each object
file means that the stream objects are guaranteed to be set up before
any of your code which uses them could run, thereby meeting the
requirements of the standard.
</p><p>The penalty, of course, is that after the first copy of
<span class="emphasis"><em>__foo</em></span> is constructed, all the others are just wasted
processor time. The time spent is merely for an increment-and-test
inside a function call, but over several dozen or hundreds of object
files, that time can add up. (It's not in a tight loop, either.)
</p><p>The lesson? Only include &lt;iostream&gt; when you need to use one of
the standard objects in that source file; you'll pay less startup
time. Only include the header files you need to in general; your
compile times will go down when there's less parsing work to do.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="io.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="io.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt11ch25.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part XI. Input and Output </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 25. Stream Buffers</td></tr></table></div></body></html>

57
libstdc++-v3/doc/html/manual/bk01pt11ch25.html Normal file
View File

@ -0,0 +1,57 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 25. Stream Buffers</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="io.html" title="Part XI. Input and Output" /><link rel="prev" href="bk01pt11ch24.html" title="Chapter 24. Iostream Objects" /><link rel="next" href="bk01pt11ch25s02.html" title="Buffering" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 25. Stream Buffers</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt11ch24.html">Prev</a> </td><th width="60%" align="center">Part XI. Input and Output</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt11ch25s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.io.streambufs"></a>Chapter 25. Stream Buffers</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt11ch25.html#io.streambuf.derived">Derived streambuf Classes</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch25s02.html">Buffering</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="io.streambuf.derived"></a>Derived streambuf Classes</h2></div></div></div><p>
</p><p>Creating your own stream buffers for I/O can be remarkably easy.
If you are interested in doing so, we highly recommend two very
excellent books:
<a class="ulink" href="http://www.langer.camelot.de/iostreams.html" target="_top">Standard C++
IOStreams and Locales</a> by Langer and Kreft, ISBN 0-201-18395-1, and
<a class="ulink" href="http://www.josuttis.com/libbook/" target="_top">The C++ Standard Library</a>
by Nicolai Josuttis, ISBN 0-201-37926-0. Both are published by
Addison-Wesley, who isn't paying us a cent for saying that, honest.
</p><p>Here is a simple example, io/outbuf1, from the Josuttis text. It
transforms everything sent through it to uppercase. This version
assumes many things about the nature of the character type being
used (for more information, read the books or the newsgroups):
</p><pre class="programlisting">
#include &lt;iostream&gt;
#include &lt;streambuf&gt;
#include &lt;locale&gt;
#include &lt;cstdio&gt;
class outbuf : public std::streambuf
{
protected:
/* central output function
* - print characters in uppercase mode
*/
virtual int_type overflow (int_type c) {
if (c != EOF) {
// convert lowercase to uppercase
c = std::toupper(static_cast&lt;char&gt;(c),getloc());
// and write the character to the standard output
if (putchar(c) == EOF) {
return EOF;
}
}
return c;
}
};
int main()
{
// create special output buffer
outbuf ob;
// initialize output stream with that output buffer
std::ostream out(&amp;ob);
out &lt;&lt; "31 hexadecimal: "
&lt;&lt; std::hex &lt;&lt; 31 &lt;&lt; std::endl;
return 0;
}
</pre><p>Try it yourself! More examples can be found in 3.1.x code, in
<code class="code">include/ext/*_filebuf.h</code>, and on
<a class="ulink" href="http://www.informatik.uni-konstanz.de/~kuehl/c++/iostream/" target="_top">Dietmar
Kühl's IOStreams page</a>.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt11ch24.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="io.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt11ch25s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 24. Iostream Objects </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Buffering</td></tr></table></div></body></html>

77
libstdc++-v3/doc/html/manual/bk01pt11ch25s02.html Normal file
View File

@ -0,0 +1,77 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Buffering</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt11ch25.html" title="Chapter 25. Stream Buffers" /><link rel="prev" href="bk01pt11ch25.html" title="Chapter 25. Stream Buffers" /><link rel="next" href="bk01pt11ch26.html" title="Chapter 26. Memory Based Streams" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Buffering</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt11ch25.html">Prev</a> </td><th width="60%" align="center">Chapter 25. Stream Buffers</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt11ch26.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="io.streambuf.buffering"></a>Buffering</h2></div></div></div><p>First, are you sure that you understand buffering? Particularly
the fact that C++ may not, in fact, have anything to do with it?
</p><p>The rules for buffering can be a little odd, but they aren't any
different from those of C. (Maybe that's why they can be a bit
odd.) Many people think that writing a newline to an output
stream automatically flushes the output buffer. This is true only
when the output stream is, in fact, a terminal and not a file
or some other device -- and <span class="emphasis"><em>that</em></span> may not even be true
since C++ says nothing about files nor terminals. All of that is
system-dependent. (The "newline-buffer-flushing only occurring
on terminals" thing is mostly true on Unix systems, though.)
</p><p>Some people also believe that sending <code class="code">endl</code> down an
output stream only writes a newline. This is incorrect; after a
newline is written, the buffer is also flushed. Perhaps this
is the effect you want when writing to a screen -- get the text
out as soon as possible, etc -- but the buffering is largely
wasted when doing this to a file:
</p><pre class="programlisting">
output &lt;&lt; "a line of text" &lt;&lt; endl;
output &lt;&lt; some_data_variable &lt;&lt; endl;
output &lt;&lt; "another line of text" &lt;&lt; endl; </pre><p>The proper thing to do in this case to just write the data out
and let the libraries and the system worry about the buffering.
If you need a newline, just write a newline:
</p><pre class="programlisting">
output &lt;&lt; "a line of text\n"
&lt;&lt; some_data_variable &lt;&lt; '\n'
&lt;&lt; "another line of text\n"; </pre><p>I have also joined the output statements into a single statement.
You could make the code prettier by moving the single newline to
the start of the quoted text on the last line, for example.
</p><p>If you do need to flush the buffer above, you can send an
<code class="code">endl</code> if you also need a newline, or just flush the buffer
yourself:
</p><pre class="programlisting">
output &lt;&lt; ...... &lt;&lt; flush; // can use std::flush manipulator
output.flush(); // or call a member fn </pre><p>On the other hand, there are times when writing to a file should
be like writing to standard error; no buffering should be done
because the data needs to appear quickly (a prime example is a
log file for security-related information). The way to do this is
just to turn off the buffering <span class="emphasis"><em>before any I/O operations at
all</em></span> have been done (note that opening counts as an I/O operation):
</p><pre class="programlisting">
std::ofstream os;
std::ifstream is;
int i;
os.rdbuf()-&gt;pubsetbuf(0,0);
is.rdbuf()-&gt;pubsetbuf(0,0);
os.open("/foo/bar/baz");
is.open("/qux/quux/quuux");
...
os &lt;&lt; "this data is written immediately\n";
is &gt;&gt; i; // and this will probably cause a disk read </pre><p>Since all aspects of buffering are handled by a streambuf-derived
member, it is necessary to get at that member with <code class="code">rdbuf()</code>.
Then the public version of <code class="code">setbuf</code> can be called. The
arguments are the same as those for the Standard C I/O Library
function (a buffer area followed by its size).
</p><p>A great deal of this is implementation-dependent. For example,
<code class="code">streambuf</code> does not specify any actions for its own
<code class="code">setbuf()</code>-ish functions; the classes derived from
<code class="code">streambuf</code> each define behavior that "makes
sense" for that class: an argument of (0,0) turns off buffering
for <code class="code">filebuf</code> but does nothing at all for its siblings
<code class="code">stringbuf</code> and <code class="code">strstreambuf</code>, and specifying
anything other than (0,0) has varying effects.
User-defined classes derived from <code class="code">streambuf</code> can
do whatever they want. (For <code class="code">filebuf</code> and arguments for
<code class="code">(p,s)</code> other than zeros, libstdc++ does what you'd expect:
the first <code class="code">s</code> bytes of <code class="code">p</code> are used as a buffer,
which you must allocate and deallocate.)
</p><p>A last reminder: there are usually more buffers involved than
just those at the language/library level. Kernel buffers, disk
buffers, and the like will also have an effect. Inspecting and
changing those are system-dependent.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt11ch25.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt11ch25.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt11ch26.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 25. Stream Buffers </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 26. Memory Based Streams</td></tr></table></div></body></html>

34
libstdc++-v3/doc/html/manual/bk01pt11ch26.html Normal file
View File

@ -0,0 +1,34 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 26. Memory Based Streams</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="io.html" title="Part XI. Input and Output" /><link rel="prev" href="bk01pt11ch25s02.html" title="Buffering" /><link rel="next" href="bk01pt11ch27.html" title="Chapter 27. File Based Streams" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 26. Memory Based Streams</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt11ch25s02.html">Prev</a> </td><th width="60%" align="center">Part XI. Input and Output</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt11ch27.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.io.memstreams"></a>Chapter 26. Memory Based Streams</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt11ch26.html#manual.io.memstreams.compat">Compatibility With strstream</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.io.memstreams.compat"></a>Compatibility With strstream</h2></div></div></div><p>
</p><p>Stringstreams (defined in the header <code class="code">&lt;sstream&gt;</code>)
are in this author's opinion one of the coolest things since
sliced time. An example of their use is in the Received Wisdom
section for Chapter 21 (Strings),
<a class="ulink" href="../21_strings/howto.html#1.1internal" target="_top"> describing how to
format strings</a>.
</p><p>The quick definition is: they are siblings of ifstream and ofstream,
and they do for <code class="code">std::string</code> what their siblings do for
files. All that work you put into writing <code class="code">&lt;&lt;</code> and
<code class="code">&gt;&gt;</code> functions for your classes now pays off
<span class="emphasis"><em>again!</em></span> Need to format a string before passing the string
to a function? Send your stuff via <code class="code">&lt;&lt;</code> to an
ostringstream. You've read a string as input and need to parse it?
Initialize an istringstream with that string, and then pull pieces
out of it with <code class="code">&gt;&gt;</code>. Have a stringstream and need to
get a copy of the string inside? Just call the <code class="code">str()</code>
member function.
</p><p>This only works if you've written your
<code class="code">&lt;&lt;</code>/<code class="code">&gt;&gt;</code> functions correctly, though,
and correctly means that they take istreams and ostreams as
parameters, not i<span class="emphasis"><em>f</em></span>streams and o<span class="emphasis"><em>f</em></span>streams. If they
take the latter, then your I/O operators will work fine with
file streams, but with nothing else -- including stringstreams.
</p><p>If you are a user of the strstream classes, you need to update
your code. You don't have to explicitly append <code class="code">ends</code> to
terminate the C-style character array, you don't have to mess with
"freezing" functions, and you don't have to manage the
memory yourself. The strstreams have been officially deprecated,
which means that 1) future revisions of the C++ Standard won't
support them, and 2) if you use them, people will laugh at you.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt11ch25s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="io.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt11ch27.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Buffering </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 27. File Based Streams</td></tr></table></div></body></html>

49
libstdc++-v3/doc/html/manual/bk01pt11ch27.html Normal file
View File

@ -0,0 +1,49 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 27. File Based Streams</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="io.html" title="Part XI. Input and Output" /><link rel="prev" href="bk01pt11ch26.html" title="Chapter 26. Memory Based Streams" /><link rel="next" href="bk01pt11ch27s02.html" title="Binary Input and Output" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 27. File Based Streams</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt11ch26.html">Prev</a> </td><th width="60%" align="center">Part XI. Input and Output</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt11ch27s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.io.filestreams"></a>Chapter 27. File Based Streams</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt11ch27.html#manual.io.filestreams.copying_a_file">Copying a File</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch27s02.html">Binary Input and Output</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch27s03.html">More Binary Input and Output</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.io.filestreams.copying_a_file"></a>Copying a File</h2></div></div></div><p>
</p><p>So you want to copy a file quickly and easily, and most important,
completely portably. And since this is C++, you have an open
ifstream (call it IN) and an open ofstream (call it OUT):
</p><pre class="programlisting">
#include &lt;fstream&gt;
std::ifstream IN ("input_file");
std::ofstream OUT ("output_file"); </pre><p>Here's the easiest way to get it completely wrong:
</p><pre class="programlisting">
OUT &lt;&lt; IN;</pre><p>For those of you who don't already know why this doesn't work
(probably from having done it before), I invite you to quickly
create a simple text file called "input_file" containing
the sentence
</p><pre class="programlisting">
The quick brown fox jumped over the lazy dog.</pre><p>surrounded by blank lines. Code it up and try it. The contents
of "output_file" may surprise you.
</p><p>Seriously, go do it. Get surprised, then come back. It's worth it.
</p><p>The thing to remember is that the <code class="code">basic_[io]stream</code> classes
handle formatting, nothing else. In particular, they break up on
whitespace. The actual reading, writing, and storing of data is
handled by the <code class="code">basic_streambuf</code> family. Fortunately, the
<code class="code">operator&lt;&lt;</code> is overloaded to take an ostream and
a pointer-to-streambuf, in order to help with just this kind of
"dump the data verbatim" situation.
</p><p>Why a <span class="emphasis"><em>pointer</em></span> to streambuf and not just a streambuf? Well,
the [io]streams hold pointers (or references, depending on the
implementation) to their buffers, not the actual
buffers. This allows polymorphic behavior on the part of the buffers
as well as the streams themselves. The pointer is easily retrieved
using the <code class="code">rdbuf()</code> member function. Therefore, the easiest
way to copy the file is:
</p><pre class="programlisting">
OUT &lt;&lt; IN.rdbuf();</pre><p>So what <span class="emphasis"><em>was</em></span> happening with OUT&lt;&lt;IN? Undefined
behavior, since that particular &lt;&lt; isn't defined by the Standard.
I have seen instances where it is implemented, but the character
extraction process removes all the whitespace, leaving you with no
blank lines and only "Thequickbrownfox...". With
libraries that do not define that operator, IN (or one of IN's
member pointers) sometimes gets converted to a void*, and the output
file then contains a perfect text representation of a hexadecimal
address (quite a big surprise). Others don't compile at all.
</p><p>Also note that none of this is specific to o<span class="emphasis"><em>*f*</em></span>streams.
The operators shown above are all defined in the parent
basic_ostream class and are therefore available with all possible
descendants.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt11ch26.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="io.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt11ch27s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 26. Memory Based Streams </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Binary Input and Output</td></tr></table></div></body></html>

95
libstdc++-v3/doc/html/manual/bk01pt11ch27s02.html Normal file
View File

@ -0,0 +1,95 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Binary Input and Output</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt11ch27.html" title="Chapter 27. File Based Streams" /><link rel="prev" href="bk01pt11ch27.html" title="Chapter 27. File Based Streams" /><link rel="next" href="bk01pt11ch27s03.html" title="More Binary Input and Output" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Binary Input and Output</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt11ch27.html">Prev</a> </td><th width="60%" align="center">Chapter 27. File Based Streams</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt11ch27s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.io.filestreams.binary"></a>Binary Input and Output</h2></div></div></div><p>
</p><p>The first and most important thing to remember about binary I/O is
that opening a file with <code class="code">ios::binary</code> is not, repeat
<span class="emphasis"><em>not</em></span>, the only thing you have to do. It is not a silver
bullet, and will not allow you to use the <code class="code">&lt;&lt;/&gt;&gt;</code>
operators of the normal fstreams to do binary I/O.
</p><p>Sorry. Them's the breaks.
</p><p>This isn't going to try and be a complete tutorial on reading and
writing binary files (because "binary"
<a class="ulink" href="#7" target="_top">covers a lot of ground)</a>, but we will try and clear
up a couple of misconceptions and common errors.
</p><p>First, <code class="code">ios::binary</code> has exactly one defined effect, no more
and no less. Normal text mode has to be concerned with the newline
characters, and the runtime system will translate between (for
example) '\n' and the appropriate end-of-line sequence (LF on Unix,
CRLF on DOS, CR on Macintosh, etc). (There are other things that
normal mode does, but that's the most obvious.) Opening a file in
binary mode disables this conversion, so reading a CRLF sequence
under Windows won't accidentally get mapped to a '\n' character, etc.
Binary mode is not supposed to suddenly give you a bitstream, and
if it is doing so in your program then you've discovered a bug in
your vendor's compiler (or some other part of the C++ implementation,
possibly the runtime system).
</p><p>Second, using <code class="code">&lt;&lt;</code> to write and <code class="code">&gt;&gt;</code> to
read isn't going to work with the standard file stream classes, even
if you use <code class="code">skipws</code> during reading. Why not? Because
ifstream and ofstream exist for the purpose of <span class="emphasis"><em>formatting</em></span>,
not reading and writing. Their job is to interpret the data into
text characters, and that's exactly what you don't want to happen
during binary I/O.
</p><p>Third, using the <code class="code">get()</code> and <code class="code">put()/write()</code> member
functions still aren't guaranteed to help you. These are
"unformatted" I/O functions, but still character-based.
(This may or may not be what you want, see below.)
</p><p>Notice how all the problems here are due to the inappropriate use
of <span class="emphasis"><em>formatting</em></span> functions and classes to perform something
which <span class="emphasis"><em>requires</em></span> that formatting not be done? There are a
seemingly infinite number of solutions, and a few are listed here:
</p><div class="itemizedlist"><ul type="disc"><li><p>“<span class="quote">Derive your own fstream-type classes and write your own
&lt;&lt;/&gt;&gt; operators to do binary I/O on whatever data
types you're using.</span>”
</p><p>
This is a Bad Thing, because while
the compiler would probably be just fine with it, other humans
are going to be confused. The overloaded bitshift operators
have a well-defined meaning (formatting), and this breaks it.
</p></li><li><p>
“<span class="quote">Build the file structure in memory, then
<code class="code">mmap()</code> the file and copy the
structure.
</span>”
</p><p>
Well, this is easy to make work, and easy to break, and is
pretty equivalent to using <code class="code">::read()</code> and
<code class="code">::write()</code> directly, and makes no use of the
iostream library at all...
</p></li><li><p>
“<span class="quote">Use streambufs, that's what they're there for.</span>”
</p><p>
While not trivial for the beginner, this is the best of all
solutions. The streambuf/filebuf layer is the layer that is
responsible for actual I/O. If you want to use the C++
library for binary I/O, this is where you start.
</p></li></ul></div><p>How to go about using streambufs is a bit beyond the scope of this
document (at least for now), but while streambufs go a long way,
they still leave a couple of things up to you, the programmer.
As an example, byte ordering is completely between you and the
operating system, and you have to handle it yourself.
</p><p>Deriving a streambuf or filebuf
class from the standard ones, one that is specific to your data
types (or an abstraction thereof) is probably a good idea, and
lots of examples exist in journals and on Usenet. Using the
standard filebufs directly (either by declaring your own or by
using the pointer returned from an fstream's <code class="code">rdbuf()</code>)
is certainly feasible as well.
</p><p>One area that causes problems is trying to do bit-by-bit operations
with filebufs. C++ is no different from C in this respect: I/O
must be done at the byte level. If you're trying to read or write
a few bits at a time, you're going about it the wrong way. You
must read/write an integral number of bytes and then process the
bytes. (For example, the streambuf functions take and return
variables of type <code class="code">int_type</code>.)
</p><p>Another area of problems is opening text files in binary mode.
Generally, binary mode is intended for binary files, and opening
text files in binary mode means that you now have to deal with all of
those end-of-line and end-of-file problems that we mentioned before.
An instructive thread from comp.lang.c++.moderated delved off into
this topic starting more or less at
<a class="ulink" href="http://groups.google.com/groups?oi=djq&amp;selm=an_436187505" target="_top">this</a>
article and continuing to the end of the thread. (You'll have to
sort through some flames every couple of paragraphs, but the points
made are good ones.)
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt11ch27.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt11ch27.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt11ch27s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 27. File Based Streams </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> More Binary Input and Output</td></tr></table></div></body></html>

22
libstdc++-v3/doc/html/manual/bk01pt11ch27s03.html Normal file
View File

@ -0,0 +1,22 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>More Binary Input and Output</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt11ch27.html" title="Chapter 27. File Based Streams" /><link rel="prev" href="bk01pt11ch27s02.html" title="Binary Input and Output" /><link rel="next" href="bk01pt11ch28.html" title="Chapter 28. Interacting with C" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">More Binary Input and Output</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt11ch27s02.html">Prev</a> </td><th width="60%" align="center">Chapter 27. File Based Streams</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt11ch28.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.io.filestreams.binary2"></a>More Binary Input and Output</h2></div></div></div><p>Towards the beginning of February 2001, the subject of
"binary" I/O was brought up in a couple of places at the
same time. One notable place was Usenet, where James Kanze and
Dietmar Kühl separately posted articles on why attempting
generic binary I/O was not a good idea. (Here are copies of
<a class="ulink" href="binary_iostreams_kanze.txt" target="_top">Kanze's article</a> and
<a class="ulink" href="binary_iostreams_kuehl.txt" target="_top">Kühl's article</a>.)
</p><p>Briefly, the problems of byte ordering and type sizes mean that
the unformatted functions like <code class="code">ostream::put()</code> and
<code class="code">istream::get()</code> cannot safely be used to communicate
between arbitrary programs, or across a network, or from one
invocation of a program to another invocation of the same program
on a different platform, etc.
</p><p>The entire Usenet thread is instructive, and took place under the
subject heading "binary iostreams" on both comp.std.c++
and comp.lang.c++.moderated in parallel. Also in that thread,
Dietmar Kühl mentioned that he had written a pair of stream
classes that would read and write XDR, which is a good step towards
a portable binary format.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt11ch27s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt11ch27.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt11ch28.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Binary Input and Output </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 28. Interacting with C</td></tr></table></div></body></html>

8
libstdc++-v3/doc/html/manual/bk01pt11ch28.html Normal file
View File

@ -0,0 +1,8 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 28. Interacting with C</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="io.html" title="Part XI. Input and Output" /><link rel="prev" href="bk01pt11ch27s03.html" title="More Binary Input and Output" /><link rel="next" href="bk01pt11ch28s02.html" title="Performance" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 28. Interacting with C</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt11ch27s03.html">Prev</a> </td><th width="60%" align="center">Part XI. Input and Output</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt11ch28s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.io.c"></a>Chapter 28. Interacting with C</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt11ch28.html#manual.io.c.FILE">Using FILE* and file descriptors</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch28s02.html">Performance</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.io.c.FILE"></a>Using FILE* and file descriptors</h2></div></div></div><p>
See the <a class="link" href="bk01pt12ch38.html" title="Chapter 38. Input and Output">extensions</a> for using
<span class="type">FILE</span> and <span class="type">file descriptors</span> with
<code class="classname">ofstream</code> and
<code class="classname">ifstream</code>.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt11ch27s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="io.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt11ch28s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">More Binary Input and Output </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Performance</td></tr></table></div></body></html>

46
libstdc++-v3/doc/html/manual/bk01pt11ch28s02.html Normal file
View File

@ -0,0 +1,46 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Performance</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt11ch28.html" title="Chapter 28. Interacting with C" /><link rel="prev" href="bk01pt11ch28.html" title="Chapter 28. Interacting with C" /><link rel="next" href="extensions.html" title="Part XII. Extensions" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Performance</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt11ch28.html">Prev</a> </td><th width="60%" align="center">Chapter 28. Interacting with C</th><td width="20%" align="right"> <a accesskey="n" href="extensions.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.io.c.sync"></a>Performance</h2></div></div></div><p>
Pathetic Performance? Ditch C.
</p><p>It sounds like a flame on C, but it isn't. Really. Calm down.
I'm just saying it to get your attention.
</p><p>Because the C++ library includes the C library, both C-style and
C++-style I/O have to work at the same time. For example:
</p><pre class="programlisting">
#include &lt;iostream&gt;
#include &lt;cstdio&gt;
std::cout &lt;&lt; "Hel";
std::printf ("lo, worl");
std::cout &lt;&lt; "d!\n";
</pre><p>This must do what you think it does.
</p><p>Alert members of the audience will immediately notice that buffering
is going to make a hash of the output unless special steps are taken.
</p><p>The special steps taken by libstdc++, at least for version 3.0,
involve doing very little buffering for the standard streams, leaving
most of the buffering to the underlying C library. (This kind of
thing is tricky to get right.)
The upside is that correctness is ensured. The downside is that
writing through <code class="code">cout</code> can quite easily lead to awful
performance when the C++ I/O library is layered on top of the C I/O
library (as it is for 3.0 by default). Some patches have been applied
which improve the situation for 3.1.
</p><p>However, the C and C++ standard streams only need to be kept in sync
when both libraries' facilities are in use. If your program only uses
C++ I/O, then there's no need to sync with the C streams. The right
thing to do in this case is to call
</p><pre class="programlisting">
#include <span class="emphasis"><em>any of the I/O headers such as ios, iostream, etc</em></span>
std::ios::sync_with_stdio(false);
</pre><p>You must do this before performing any I/O via the C++ stream objects.
Once you call this, the C++ streams will operate independently of the
(unused) C streams. For GCC 3.x, this means that <code class="code">cout</code> and
company will become fully buffered on their own.
</p><p>Note, by the way, that the synchronization requirement only applies to
the standard streams (<code class="code">cin</code>, <code class="code">cout</code>,
<code class="code">cerr</code>,
<code class="code">clog</code>, and their wide-character counterparts). File stream
objects that you declare yourself have no such requirement and are fully
buffered.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt11ch28.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt11ch28.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="extensions.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 28. Interacting with C </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part XII. Extensions</td></tr></table></div></body></html>

37
libstdc++-v3/doc/html/manual/bk01pt12ch29.html Normal file
View File

@ -0,0 +1,37 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 29. Compile Time Checks</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII. Extensions" /><link rel="prev" href="bk01pt12pr03.html" title="" /><link rel="next" href="debug_mode.html" title="Chapter 30. Debug Mode" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 29. Compile Time Checks</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12pr03.html">Prev</a> </td><th width="60%" align="center">Part XII. Extensions</th><td width="20%" align="right"> <a accesskey="n" href="debug_mode.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.compile_checks"></a>Chapter 29. Compile Time Checks</h2></div></div></div><p>
Also known as concept checking.
</p><p>In 1999, SGI added <span class="emphasis"><em>concept checkers</em></span> to their implementation
of the STL: code which checked the template parameters of
instantiated pieces of the STL, in order to insure that the parameters
being used met the requirements of the standard. For example,
the Standard requires that types passed as template parameters to
<code class="code">vector</code> be “<span class="quote">Assignable</span>” (which means what you think
it means). The checking was done during compilation, and none of
the code was executed at runtime.
</p><p>Unfortunately, the size of the compiler files grew significantly
as a result. The checking code itself was cumbersome. And bugs
were found in it on more than one occasion.
</p><p>The primary author of the checking code, Jeremy Siek, had already
started work on a replacement implementation. The new code has been
formally reviewed and accepted into
<a class="ulink" href="http://www.boost.org/libs/concept_check/concept_check.htm" target="_top">the
Boost libraries</a>, and we are pleased to incorporate it into the
GNU C++ library.
</p><p>The new version imposes a much smaller space overhead on the generated
object file. The checks are also cleaner and easier to read and
understand.
</p><p>They are off by default for all versions of GCC from 3.0 to 3.4 (the
latest release at the time of writing).
They can be enabled at configure time with
<a class="ulink" href="../configopts.html" target="_top"><code class="literal">--enable-concept-checks</code></a>.
You can enable them on a per-translation-unit basis with
<code class="code">#define _GLIBCXX_CONCEPT_CHECKS</code> for GCC 3.4 and higher
(or with <code class="code">#define _GLIBCPP_CONCEPT_CHECKS</code> for versions
3.1, 3.2 and 3.3).
</p><p>Please note that the upcoming C++ standard has first-class
support for template parameter constraints based on concepts in the core
language. This will obviate the need for the library-simulated concept
checking described above.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12pr03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="debug_mode.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 30. Debug Mode</td></tr></table></div></body></html>

55
libstdc++-v3/doc/html/manual/bk01pt12ch30s02.html Normal file
View File

@ -0,0 +1,55 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Semantics</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; debug&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="debug_mode.html" title="Chapter 30. Debug Mode" /><link rel="prev" href="debug_mode.html" title="Chapter 30. Debug Mode" /><link rel="next" href="bk01pt12ch30s03.html" title="Using" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Semantics</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="debug_mode.html">Prev</a> </td><th width="60%" align="center">Chapter 30. Debug Mode</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch30s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.debug_mode.semantics"></a>Semantics</h2></div></div></div><p>
</p><p>A program that uses the C++ standard library correctly
will maintain the same semantics under debug mode as it had with
the normal (release) library. All functional and exception-handling
guarantees made by the normal library also hold for the debug mode
library, with one exception: performance guarantees made by the
normal library may not hold in the debug mode library. For
instance, erasing an element in a <code class="code">std::list</code> is a
constant-time operation in normal library, but in debug mode it is
linear in the number of iterators that reference that particular
list. So while your (correct) program won't change its results, it
is likely to execute more slowly.</p><p>libstdc++ includes many extensions to the C++ standard library. In
some cases the extensions are obvious, such as the hashed
associative containers, whereas other extensions give predictable
results to behavior that would otherwise be undefined, such as
throwing an exception when a <code class="code">std::basic_string</code> is
constructed from a NULL character pointer. This latter category also
includes implementation-defined and unspecified semantics, such as
the growth rate of a vector. Use of these extensions is not
considered incorrect, so code that relies on them will not be
rejected by debug mode. However, use of these extensions may affect
the portability of code to other implementations of the C++ standard
library, and is therefore somewhat hazardous. For this reason, the
libstdc++ debug mode offers a "pedantic" mode (similar to
GCC's <code class="code">-pedantic</code> compiler flag) that attempts to emulate
the semantics guaranteed by the C++ standard. For
instance, constructing a <code class="code">std::basic_string</code> with a NULL
character pointer would result in an exception under normal mode or
non-pedantic debug mode (this is a libstdc++ extension), whereas
under pedantic debug mode libstdc++ would signal an error. To enable
the pedantic debug mode, compile your program with
both <code class="code">-D_GLIBCXX_DEBUG</code>
and <code class="code">-D_GLIBCXX_DEBUG_PEDANTIC</code> .
(N.B. In GCC 3.4.x and 4.0.0, due to a bug,
<code class="code">-D_GLIBXX_DEBUG_PEDANTIC</code> was also needed. The problem has
been fixed in GCC 4.0.1 and later versions.) </p><p>The following library components provide extra debugging
capabilities in debug mode:</p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">std::basic_string</code> (no safe iterators and see note below)</p></li><li><p><code class="code">std::bitset</code></p></li><li><p><code class="code">std::deque</code></p></li><li><p><code class="code">std::list</code></p></li><li><p><code class="code">std::map</code></p></li><li><p><code class="code">std::multimap</code></p></li><li><p><code class="code">std::multiset</code></p></li><li><p><code class="code">std::set</code></p></li><li><p><code class="code">std::vector</code></p></li><li><p><code class="code">std::unordered_map</code></p></li><li><p><code class="code">std::unordered_multimap</code></p></li><li><p><code class="code">std::unordered_set</code></p></li><li><p><code class="code">std::unordered_multiset</code></p></li></ul></div><p>N.B. although there are precondition checks for some string operations,
e.g. <code class="code">operator[]</code>,
they will not always be run when using the <code class="code">char</code> and
<code class="code">wchar_t</code> specialisations (<code class="code">std::string</code> and
<code class="code">std::wstring</code>). This is because libstdc++ uses GCC's
<code class="code">extern template</code> extension to provide explicit instantiations
of <code class="code">std::string</code> and <code class="code">std::wstring</code>, and those
explicit instantiations don't include the debug-mode checks. If the
containing functions are inlined then the checks will run, so compiling
with <code class="code">-O1</code> might be enough to enable them. Alternatively
<code class="code">-D_GLIBCXX_EXTERN_TEMPLATE=0</code> will suppress the declarations
of the explicit instantiations and cause the functions to be instantiated
with the debug-mode checks included, but this is unsupported and not
guaranteed to work. For full debug-mode support you can use the
<code class="code">__gnu_debug::basic_string</code> debugging container directly,
which always works correctly.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="debug_mode.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="debug_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch30s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 30. Debug Mode </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Using</td></tr></table></div></body></html>

24
libstdc++-v3/doc/html/manual/bk01pt12ch30s03.html Normal file
View File

@ -0,0 +1,24 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Using</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; debug&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="debug_mode.html" title="Chapter 30. Debug Mode" /><link rel="prev" href="bk01pt12ch30s02.html" title="Semantics" /><link rel="next" href="bk01pt12ch30s04.html" title="Design" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Using</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch30s02.html">Prev</a> </td><th width="60%" align="center">Chapter 30. Debug Mode</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch30s04.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.debug_mode.using"></a>Using</h2></div></div></div><p>
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="debug_mode.using.mode"></a>Using the Debug Mode</h3></div></div></div><p>To use the libstdc++ debug mode, compile your application with the
compiler flag <code class="code">-D_GLIBCXX_DEBUG</code>. Note that this flag
changes the sizes and behavior of standard class templates such
as <code class="code">std::vector</code>, and therefore you can only link code
compiled with debug mode and code compiled without debug mode if no
instantiation of a container is passed between the two translation
units.</p><p>By default, error messages are formatted to fit on lines of about
78 characters. The environment variable
<code class="code">GLIBCXX_DEBUG_MESSAGE_LENGTH</code> can be used to request a
different length.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="debug_mode.using.specific"></a>Using a Specific Debug Container</h3></div></div></div><p>When it is not feasible to recompile your entire application, or
only specific containers need checking, debugging containers are
available as GNU extensions. These debugging containers are
functionally equivalent to the standard drop-in containers used in
debug mode, but they are available in a separate namespace as GNU
extensions and may be used in programs compiled with either release
mode or with debug mode. The
following table provides the names and headers of the debugging
containers:
</p><div class="table"><a id="id400605"></a><p class="title"><b>Table 30.1. Debugging Containers</b></p><div class="table-contents"><table summary="Debugging Containers" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col /><col /></colgroup><thead><tr><th align="left">Container</th><th align="left">Header</th><th align="left">Debug container</th><th align="left">Debug header</th><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></thead><tbody><tr><td align="left"><code class="classname">std::bitset</code></td><td align="left"><code class="filename">bitset</code></td><td align="left"><code class="classname">__gnu_debug::bitset</code></td><td align="left"><code class="filename">bitset</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::deque</code></td><td align="left"><code class="filename">deque</code></td><td align="left"><code class="classname">__gnu_debug::deque</code></td><td align="left"><code class="filename">deque</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::list</code></td><td align="left"><code class="filename">list</code></td><td align="left"><code class="classname">__gnu_debug::list</code></td><td align="left"><code class="filename">list</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::map</code></td><td align="left"><code class="filename">map</code></td><td align="left"><code class="classname">__gnu_debug::map</code></td><td align="left"><code class="filename">map</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::multimap</code></td><td align="left"><code class="filename">map</code></td><td align="left"><code class="classname">__gnu_debug::multimap</code></td><td align="left"><code class="filename">map</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::multiset</code></td><td align="left"><code class="filename">set</code></td><td align="left"><code class="classname">__gnu_debug::multiset</code></td><td align="left"><code class="filename">set</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::set</code></td><td align="left"><code class="filename">set</code></td><td align="left"><code class="classname">__gnu_debug::set</code></td><td align="left"><code class="filename">set</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::string</code></td><td align="left"><code class="filename">string</code></td><td align="left"><code class="classname">__gnu_debug::string</code></td><td align="left"><code class="filename">string</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::wstring</code></td><td align="left"><code class="filename">string</code></td><td align="left"><code class="classname">__gnu_debug::wstring</code></td><td align="left"><code class="filename">string</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::basic_string</code></td><td align="left"><code class="filename">string</code></td><td align="left"><code class="classname">__gnu_debug::basic_string</code></td><td align="left"><code class="filename">string</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::vector</code></td><td align="left"><code class="filename">vector</code></td><td align="left"><code class="classname">__gnu_debug::vector</code></td><td align="left"><code class="filename">vector</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p>In addition, when compiling in C++0x mode, these additional
containers have additional debug capability.
</p><div class="table"><a id="id452759"></a><p class="title"><b>Table 30.2. Debugging Containers C++0x</b></p><div class="table-contents"><table summary="Debugging Containers C++0x" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col /><col /></colgroup><thead><tr><th align="left">Container</th><th align="left">Header</th><th align="left">Debug container</th><th align="left">Debug header</th><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></thead><tbody><tr><td align="left"><code class="classname">std::unordered_map</code></td><td align="left"><code class="filename">unordered_map</code></td><td align="left"><code class="classname">__gnu_debug::unordered_map</code></td><td align="left"><code class="filename">unordered_map</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::unordered_multimap</code></td><td align="left"><code class="filename">unordered_map</code></td><td align="left"><code class="classname">__gnu_debug::unordered_multimap</code></td><td align="left"><code class="filename">unordered_map</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::unordered_set</code></td><td align="left"><code class="filename">unordered_set</code></td><td align="left"><code class="classname">__gnu_debug::unordered_set</code></td><td align="left"><code class="filename">unordered_set</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::unordered_multiset</code></td><td align="left"><code class="filename">unordered_set</code></td><td align="left"><code class="classname">__gnu_debug::unordered_multiset</code></td><td align="left"><code class="filename">unordered_set</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch30s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="debug_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch30s04.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Semantics </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Design</td></tr></table></div></body></html>

409
libstdc++-v3/doc/html/manual/bk01pt12ch30s04.html Normal file
View File

@ -0,0 +1,409 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Design</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; debug&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="debug_mode.html" title="Chapter 30. Debug Mode" /><link rel="prev" href="bk01pt12ch30s03.html" title="Using" /><link rel="next" href="parallel_mode.html" title="Chapter 31. Parallel Mode" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Design</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch30s03.html">Prev</a> </td><th width="60%" align="center">Chapter 30. Debug Mode</th><td width="20%" align="right"> <a accesskey="n" href="parallel_mode.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.debug_mode.design"></a>Design</h2></div></div></div><p>
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.debug_mode.design.goals"></a>Goals</h3></div></div></div><p>
</p><p> The libstdc++ debug mode replaces unsafe (but efficient) standard
containers and iterators with semantically equivalent safe standard
containers and iterators to aid in debugging user programs. The
following goals directed the design of the libstdc++ debug mode:</p><div class="itemizedlist"><ul type="disc"><li><p><span class="emphasis"><em>Correctness</em></span>: the libstdc++ debug mode must not change
the semantics of the standard library for all cases specified in
the ANSI/ISO C++ standard. The essence of this constraint is that
any valid C++ program should behave in the same manner regardless
of whether it is compiled with debug mode or release mode. In
particular, entities that are defined in namespace std in release
mode should remain defined in namespace std in debug mode, so that
legal specializations of namespace std entities will remain
valid. A program that is not valid C++ (e.g., invokes undefined
behavior) is not required to behave similarly, although the debug
mode will abort with a diagnostic when it detects undefined
behavior.</p></li><li><p><span class="emphasis"><em>Performance</em></span>: the additional of the libstdc++ debug mode
must not affect the performance of the library when it is compiled
in release mode. Performance of the libstdc++ debug mode is
secondary (and, in fact, will be worse than the release
mode).</p></li><li><p><span class="emphasis"><em>Usability</em></span>: the libstdc++ debug mode should be easy to
use. It should be easily incorporated into the user's development
environment (e.g., by requiring only a single new compiler switch)
and should produce reasonable diagnostics when it detects a
problem with the user program. Usability also involves detection
of errors when using the debug mode incorrectly, e.g., by linking
a release-compiled object against a debug-compiled object if in
fact the resulting program will not run correctly.</p></li><li><p><span class="emphasis"><em>Minimize recompilation</em></span>: While it is expected that
users recompile at least part of their program to use debug
mode, the amount of recompilation affects the
detect-compile-debug turnaround time. This indirectly affects the
usefulness of the debug mode, because debugging some applications
may require rebuilding a large amount of code, which may not be
feasible when the suspect code may be very localized. There are
several levels of conformance to this requirement, each with its
own usability and implementation characteristics. In general, the
higher-numbered conformance levels are more usable (i.e., require
less recompilation) but are more complicated to implement than
the lower-numbered conformance levels.
</p><div class="orderedlist"><ol type="1"><li><p><span class="emphasis"><em>Full recompilation</em></span>: The user must recompile his or
her entire application and all C++ libraries it depends on,
including the C++ standard library that ships with the
compiler. This must be done even if only a small part of the
program can use debugging features.</p></li><li><p><span class="emphasis"><em>Full user recompilation</em></span>: The user must recompile
his or her entire application and all C++ libraries it depends
on, but not the C++ standard library itself. This must be done
even if only a small part of the program can use debugging
features. This can be achieved given a full recompilation
system by compiling two versions of the standard library when
the compiler is installed and linking against the appropriate
one, e.g., a multilibs approach.</p></li><li><p><span class="emphasis"><em>Partial recompilation</em></span>: The user must recompile the
parts of his or her application and the C++ libraries it
depends on that will use the debugging facilities
directly. This means that any code that uses the debuggable
standard containers would need to be recompiled, but code
that does not use them (but may, for instance, use IOStreams)
would not have to be recompiled.</p></li><li><p><span class="emphasis"><em>Per-use recompilation</em></span>: The user must recompile the
parts of his or her application and the C++ libraries it
depends on where debugging should occur, and any other code
that interacts with those containers. This means that a set of
translation units that accesses a particular standard
container instance may either be compiled in release mode (no
checking) or debug mode (full checking), but must all be
compiled in the same way; a translation unit that does not see
that standard container instance need not be recompiled. This
also means that a translation unit <span class="emphasis"><em>A</em></span> that contains a
particular instantiation
(say, <code class="code">std::vector&lt;int&gt;</code>) compiled in release
mode can be linked against a translation unit <span class="emphasis"><em>B</em></span> that
contains the same instantiation compiled in debug mode (a
feature not present with partial recompilation). While this
behavior is technically a violation of the One Definition
Rule, this ability tends to be very important in
practice. The libstdc++ debug mode supports this level of
recompilation. </p></li><li><p><span class="emphasis"><em>Per-unit recompilation</em></span>: The user must only
recompile the translation units where checking should occur,
regardless of where debuggable standard containers are
used. This has also been dubbed "<code class="code">-g</code> mode",
because the <code class="code">-g</code> compiler switch works in this way,
emitting debugging information at a per--translation-unit
granularity. We believe that this level of recompilation is in
fact not possible if we intend to supply safe iterators, leave
the program semantics unchanged, and not regress in
performance under release mode because we cannot associate
extra information with an iterator (to form a safe iterator)
without either reserving that space in release mode
(performance regression) or allocating extra memory associated
with each iterator with <code class="code">new</code> (changes the program
semantics).</p></li></ol></div><p>
</p></li></ul></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.debug_mode.design.methods"></a>Methods</h3></div></div></div><p>
</p><p>This section provides an overall view of the design of the
libstdc++ debug mode and details the relationship between design
decisions and the stated design goals.</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="debug_mode.design.methods.wrappers"></a>The Wrapper Model</h4></div></div></div><p>The libstdc++ debug mode uses a wrapper model where the debugging
versions of library components (e.g., iterators and containers) form
a layer on top of the release versions of the library
components. The debugging components first verify that the operation
is correct (aborting with a diagnostic if an error is found) and
will then forward to the underlying release-mode container that will
perform the actual work. This design decision ensures that we cannot
regress release-mode performance (because the release-mode
containers are left untouched) and partially enables <a class="ulink" href="#mixing" target="_top">mixing debug and release code</a> at link time,
although that will not be discussed at this time.</p><p>Two types of wrappers are used in the implementation of the debug
mode: container wrappers and iterator wrappers. The two types of
wrappers interact to maintain relationships between iterators and
their associated containers, which are necessary to detect certain
types of standard library usage errors such as dereferencing
past-the-end iterators or inserting into a container using an
iterator from a different container.</p><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="debug_mode.design.methods.safe_iter"></a>Safe Iterators</h5></div></div></div><p>Iterator wrappers provide a debugging layer over any iterator that
is attached to a particular container, and will manage the
information detailing the iterator's state (singular,
dereferenceable, etc.) and tracking the container to which the
iterator is attached. Because iterators have a well-defined, common
interface the iterator wrapper is implemented with the iterator
adaptor class template <code class="code">__gnu_debug::_Safe_iterator</code>,
which takes two template parameters:</p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">Iterator</code>: The underlying iterator type, which must
be either the <code class="code">iterator</code> or <code class="code">const_iterator</code>
typedef from the sequence type this iterator can reference.</p></li><li><p><code class="code">Sequence</code>: The type of sequence that this iterator
references. This sequence must be a safe sequence (discussed below)
whose <code class="code">iterator</code> or <code class="code">const_iterator</code> typedef
is the type of the safe iterator.</p></li></ul></div></div><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="debug_mode.design.methods.safe_seq"></a>Safe Sequences (Containers)</h5></div></div></div><p>Container wrappers provide a debugging layer over a particular
container type. Because containers vary greatly in the member
functions they support and the semantics of those member functions
(especially in the area of iterator invalidation), container
wrappers are tailored to the container they reference, e.g., the
debugging version of <code class="code">std::list</code> duplicates the entire
interface of <code class="code">std::list</code>, adding additional semantic
checks and then forwarding operations to the
real <code class="code">std::list</code> (a public base class of the debugging
version) as appropriate. However, all safe containers inherit from
the class template <code class="code">__gnu_debug::_Safe_sequence</code>,
instantiated with the type of the safe container itself (an instance
of the curiously recurring template pattern).</p><p>The iterators of a container wrapper will be
<a class="ulink" href="#safe_iterator" target="_top">safe iterators</a> that reference sequences
of this type and wrap the iterators provided by the release-mode
base class. The debugging container will use only the safe
iterators within its own interface (therefore requiring the user to
use safe iterators, although this does not change correct user
code) and will communicate with the release-mode base class with
only the underlying, unsafe, release-mode iterators that the base
class exports.</p><p> The debugging version of <code class="code">std::list</code> will have the
following basic structure:</p><pre class="programlisting">
template&lt;typename _Tp, typename _Allocator = allocator&lt;_Tp&gt;
class debug-list :
public release-list&lt;_Tp, _Allocator&gt;,
public __gnu_debug::_Safe_sequence&lt;debug-list&lt;_Tp, _Allocator&gt; &gt;
{
typedef release-list&lt;_Tp, _Allocator&gt; _Base;
typedef debug-list&lt;_Tp, _Allocator&gt; _Self;
public:
typedef __gnu_debug::_Safe_iterator&lt;typename _Base::iterator, _Self&gt; iterator;
typedef __gnu_debug::_Safe_iterator&lt;typename _Base::const_iterator, _Self&gt; const_iterator;
// duplicate std::list interface with debugging semantics
};
</pre></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="debug_mode.design.methods.precond"></a>Precondition Checking</h4></div></div></div><p>The debug mode operates primarily by checking the preconditions of
all standard library operations that it supports. Preconditions that
are always checked (regardless of whether or not we are in debug
mode) are checked via the <code class="code">__check_xxx</code> macros defined
and documented in the source
file <code class="code">include/debug/debug.h</code>. Preconditions that may or
may not be checked, depending on the debug-mode
macro <code class="code">_GLIBCXX_DEBUG</code>, are checked via
the <code class="code">__requires_xxx</code> macros defined and documented in the
same source file. Preconditions are validated using any additional
information available at run-time, e.g., the containers that are
associated with a particular iterator, the position of the iterator
within those containers, the distance between two iterators that may
form a valid range, etc. In the absence of suitable information,
e.g., an input iterator that is not a safe iterator, these
precondition checks will silently succeed.</p><p>The majority of precondition checks use the aforementioned macros,
which have the secondary benefit of having prewritten debug
messages that use information about the current status of the
objects involved (e.g., whether an iterator is singular or what
sequence it is attached to) along with some static information
(e.g., the names of the function parameters corresponding to the
objects involved). When not using these macros, the debug mode uses
either the debug-mode assertion
macro <code class="code">_GLIBCXX_DEBUG_ASSERT</code> , its pedantic
cousin <code class="code">_GLIBCXX_DEBUG_PEDASSERT</code>, or the assertion
check macro that supports more advance formulation of error
messages, <code class="code">_GLIBCXX_DEBUG_VERIFY</code>. These macros are
documented more thoroughly in the debug mode source code.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="debug_mode.design.methods.coexistence"></a>Release- and debug-mode coexistence</h4></div></div></div><p>The libstdc++ debug mode is the first debug mode we know of that
is able to provide the "Per-use recompilation" (4) guarantee, that
allows release-compiled and debug-compiled code to be linked and
executed together without causing unpredictable behavior. This
guarantee minimizes the recompilation that users are required to
perform, shortening the detect-compile-debug bughunting cycle
and making the debug mode easier to incorporate into development
environments by minimizing dependencies.</p><p>Achieving link- and run-time coexistence is not a trivial
implementation task. To achieve this goal we required a small
extension to the GNU C++ compiler (described in the GCC Manual for
C++ Extensions, see <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Strong-Using.html" target="_top">strong
using</a>), and a complex organization of debug- and
release-modes. The end result is that we have achieved per-use
recompilation but have had to give up some checking of the
<code class="code">std::basic_string</code> class template (namely, safe
iterators).
</p><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="methods.coexistence.compile"></a>Compile-time coexistence of release- and debug-mode components</h5></div></div></div><p>Both the release-mode components and the debug-mode
components need to exist within a single translation unit so that
the debug versions can wrap the release versions. However, only one
of these components should be user-visible at any particular
time with the standard name, e.g., <code class="code">std::list</code>. </p><p>In release mode, we define only the release-mode version of the
component with its standard name and do not include the debugging
component at all. The release mode version is defined within the
namespace <code class="code">std</code>. Minus the namespace associations, this
method leaves the behavior of release mode completely unchanged from
its behavior prior to the introduction of the libstdc++ debug
mode. Here's an example of what this ends up looking like, in
C++.</p><pre class="programlisting">
namespace std
{
template&lt;typename _Tp, typename _Alloc = allocator&lt;_Tp&gt; &gt;
class list
{
// ...
};
} // namespace std
</pre><p>In debug mode we include the release-mode container (which is now
defined in in the namespace <code class="code">__norm</code>) and also the
debug-mode container. The debug-mode container is defined within the
namespace <code class="code">__debug</code>, which is associated with namespace
<code class="code">std</code> via the GNU namespace association extension. This
method allows the debug and release versions of the same component to
coexist at compile-time and link-time without causing an unreasonable
maintenance burden, while minimizing confusion. Again, this boils down
to C++ code as follows:</p><pre class="programlisting">
namespace std
{
namespace __norm
{
template&lt;typename _Tp, typename _Alloc = allocator&lt;_Tp&gt; &gt;
class list
{
// ...
};
} // namespace __gnu_norm
namespace __debug
{
template&lt;typename _Tp, typename _Alloc = allocator&lt;_Tp&gt; &gt;
class list
: public __norm::list&lt;_Tp, _Alloc&gt;,
public __gnu_debug::_Safe_sequence&lt;list&lt;_Tp, _Alloc&gt; &gt;
{
// ...
};
} // namespace __norm
using namespace __debug __attribute__ ((strong));
}
</pre></div><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="methods.coexistence.link"></a>Link- and run-time coexistence of release- and
debug-mode components</h5></div></div></div><p>Because each component has a distinct and separate release and
debug implementation, there are are no issues with link-time
coexistence: the separate namespaces result in different mangled
names, and thus unique linkage.</p><p>However, components that are defined and used within the C++
standard library itself face additional constraints. For instance,
some of the member functions of <code class="code"> std::moneypunct</code> return
<code class="code">std::basic_string</code>. Normally, this is not a problem, but
with a mixed mode standard library that could be using either
debug-mode or release-mode <code class="code"> basic_string</code> objects, things
get more complicated. As the return value of a function is not
encoded into the mangled name, there is no way to specify a
release-mode or a debug-mode string. In practice, this results in
runtime errors. A simplified example of this problem is as follows.
</p><p> Take this translation unit, compiled in debug-mode: </p><pre class="programlisting">
// -D_GLIBCXX_DEBUG
#include &lt;string&gt;
std::string test02();
std::string test01()
{
return test02();
}
int main()
{
test01();
return 0;
}
</pre><p> ... and linked to this translation unit, compiled in release mode:</p><pre class="programlisting">
#include &lt;string&gt;
std::string
test02()
{
return std::string("toast");
}
</pre><p> For this reason we cannot easily provide safe iterators for
the <code class="code">std::basic_string</code> class template, as it is present
throughout the C++ standard library. For instance, locale facets
define typedefs that include <code class="code">basic_string</code>: in a mixed
debug/release program, should that typedef be based on the
debug-mode <code class="code">basic_string</code> or the
release-mode <code class="code">basic_string</code>? While the answer could be
"both", and the difference hidden via renaming a la the
debug/release containers, we must note two things about locale
facets:</p><div class="orderedlist"><ol type="1"><li><p>They exist as shared state: one can create a facet in one
translation unit and access the facet via the same type name in a
different translation unit. This means that we cannot have two
different versions of locale facets, because the types would not be
the same across debug/release-mode translation unit barriers.</p></li><li><p>They have virtual functions returning strings: these functions
mangle in the same way regardless of the mangling of their return
types (see above), and their precise signatures can be relied upon
by users because they may be overridden in derived classes.</p></li></ol></div><p>With the design of libstdc++ debug mode, we cannot effectively hide
the differences between debug and release-mode strings from the
user. Failure to hide the differences may result in unpredictable
behavior, and for this reason we have opted to only
perform <code class="code">basic_string</code> changes that do not require ABI
changes. The effect on users is expected to be minimal, as there are
simple alternatives (e.g., <code class="code">__gnu_debug::basic_string</code>),
and the usability benefit we gain from the ability to mix debug- and
release-compiled translation units is enormous.</p></div><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="methods.coexistence.alt"></a>Alternatives for Coexistence</h5></div></div></div><p>The coexistence scheme above was chosen over many alternatives,
including language-only solutions and solutions that also required
extensions to the C++ front end. The following is a partial list of
solutions, with justifications for our rejection of each.</p><div class="itemizedlist"><ul type="disc"><li><p><span class="emphasis"><em>Completely separate debug/release libraries</em></span>: This is by
far the simplest implementation option, where we do not allow any
coexistence of debug- and release-compiled translation units in a
program. This solution has an extreme negative affect on usability,
because it is quite likely that some libraries an application
depends on cannot be recompiled easily. This would not meet
our <span class="emphasis"><em>usability</em></span> or <span class="emphasis"><em>minimize recompilation</em></span> criteria
well.</p></li><li><p><span class="emphasis"><em>Add a <code class="code">Debug</code> boolean template parameter</em></span>:
Partial specialization could be used to select the debug
implementation when <code class="code">Debug == true</code>, and the state
of <code class="code">_GLIBCXX_DEBUG</code> could decide whether the
default <code class="code">Debug</code> argument is <code class="code">true</code>
or <code class="code">false</code>. This option would break conformance with the
C++ standard in both debug <span class="emphasis"><em>and</em></span> release modes. This would
not meet our <span class="emphasis"><em>correctness</em></span> criteria. </p></li><li><p><span class="emphasis"><em>Packaging a debug flag in the allocators</em></span>: We could
reuse the <code class="code">Allocator</code> template parameter of containers
by adding a sentinel wrapper <code class="code">debug&lt;&gt;</code> that
signals the user's intention to use debugging, and pick up
the <code class="code">debug&lt;&gt;</code> allocator wrapper in a partial
specialization. However, this has two drawbacks: first, there is a
conformance issue because the default allocator would not be the
standard-specified <code class="code">std::allocator&lt;T&gt;</code>. Secondly
(and more importantly), users that specify allocators instead of
implicitly using the default allocator would not get debugging
containers. Thus this solution fails the <span class="emphasis"><em>correctness</em></span>
criteria.</p></li><li><p><span class="emphasis"><em>Define debug containers in another namespace, and employ
a <code class="code">using</code> declaration (or directive)</em></span>: This is an
enticing option, because it would eliminate the need for
the <code class="code">link_name</code> extension by aliasing the
templates. However, there is no true template aliasing mechanism
is C++, because both <code class="code">using</code> directives and using
declarations disallow specialization. This method fails
the <span class="emphasis"><em>correctness</em></span> criteria.</p></li><li><p><span class="emphasis"><em> Use implementation-specific properties of anonymous
namespaces. </em></span>
See <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2003-08/msg00004.html" target="_top"> this post
</a>
This method fails the <span class="emphasis"><em>correctness</em></span> criteria.</p></li><li><p><span class="emphasis"><em>Extension: allow reopening on namespaces</em></span>: This would
allow the debug mode to effectively alias the
namespace <code class="code">std</code> to an internal namespace, such
as <code class="code">__gnu_std_debug</code>, so that it is completely
separate from the release-mode <code class="code">std</code> namespace. While
this will solve some renaming problems and ensure that
debug- and release-compiled code cannot be mixed unsafely, it ensures that
debug- and release-compiled code cannot be mixed at all. For
instance, the program would have two <code class="code">std::cout</code>
objects! This solution would fails the <span class="emphasis"><em>minimize
recompilation</em></span> requirement, because we would only be able to
support option (1) or (2).</p></li><li><p><span class="emphasis"><em>Extension: use link name</em></span>: This option involves
complicated re-naming between debug-mode and release-mode
components at compile time, and then a g++ extension called <span class="emphasis"><em>
link name </em></span> to recover the original names at link time. There
are two drawbacks to this approach. One, it's very verbose,
relying on macro renaming at compile time and several levels of
include ordering. Two, ODR issues remained with container member
functions taking no arguments in mixed-mode settings resulting in
equivalent link names, <code class="code"> vector::push_back() </code> being
one example.
See <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2003-08/msg00177.html" target="_top">link
name</a> </p></li></ul></div><p>Other options may exist for implementing the debug mode, many of
which have probably been considered and others that may still be
lurking. This list may be expanded over time to include other
options that we could have implemented, but in all cases the full
ramifications of the approach (as measured against the design goals
for a libstdc++ debug mode) should be considered first. The DejaGNU
testsuite includes some testcases that check for known problems with
some solutions (e.g., the <code class="code">using</code> declaration solution
that breaks user specialization), and additional testcases will be
added as we are able to identify other typical problem cases. These
test cases will serve as a benchmark by which we can compare debug
mode implementations.</p></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.debug_mode.design.other"></a>Other Implementations</h3></div></div></div><p>
</p><p> There are several existing implementations of debug modes for C++
standard library implementations, although none of them directly
supports debugging for programs using libstdc++. The existing
implementations include:</p><div class="itemizedlist"><ul type="disc"><li><p><a class="ulink" href="http://www.mathcs.sjsu.edu/faculty/horstman/safestl.html" target="_top">SafeSTL</a>:
SafeSTL was the original debugging version of the Standard Template
Library (STL), implemented by Cay S. Horstmann on top of the
Hewlett-Packard STL. Though it inspired much work in this area, it
has not been kept up-to-date for use with modern compilers or C++
standard library implementations.</p></li><li><p><a class="ulink" href="http://www.stlport.org/" target="_top">STLport</a>: STLport is a free
implementation of the C++ standard library derived from the <a class="ulink" href="http://www.sgi.com/tech/stl/" target="_top">SGI implementation</a>, and
ported to many other platforms. It includes a debug mode that uses a
wrapper model (that in some way inspired the libstdc++ debug mode
design), although at the time of this writing the debug mode is
somewhat incomplete and meets only the "Full user recompilation" (2)
recompilation guarantee by requiring the user to link against a
different library in debug mode vs. release mode.</p></li><li><p><a class="ulink" href="http://www.metrowerks.com/mw/default.htm" target="_top">Metrowerks
CodeWarrior</a>: The C++ standard library that ships with Metrowerks
CodeWarrior includes a debug mode. It is a full debug-mode
implementation (including debugging for CodeWarrior extensions) and
is easy to use, although it meets only the "Full recompilation" (1)
recompilation guarantee.</p></li></ul></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch30s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="debug_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="parallel_mode.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Using </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 31. Parallel Mode</td></tr></table></div></body></html>

9
libstdc++-v3/doc/html/manual/bk01pt12ch31s02.html Normal file
View File

@ -0,0 +1,9 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Semantics</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; parallel&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="parallel_mode.html" title="Chapter 31. Parallel Mode" /><link rel="prev" href="parallel_mode.html" title="Chapter 31. Parallel Mode" /><link rel="next" href="bk01pt12ch31s03.html" title="Using" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Semantics</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="parallel_mode.html">Prev</a> </td><th width="60%" align="center">Chapter 31. Parallel Mode</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch31s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.parallel_mode.semantics"></a>Semantics</h2></div></div></div><p> The parallel mode STL algorithms are currently not exception-safe,
i. e. user-defined functors must not throw exceptions.
</p><p> Since the current GCC OpenMP implementation does not support
OpenMP parallel regions in concurrent threads,
it is not possible to call parallel STL algorithm in
concurrent threads, either.
It might work with other compilers, though.</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="parallel_mode.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="parallel_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch31s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 31. Parallel Mode </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Using</td></tr></table></div></body></html>

26
libstdc++-v3/doc/html/manual/bk01pt12ch31s03.html Normal file
View File

File diff suppressed because one or more lines are too long

97
libstdc++-v3/doc/html/manual/bk01pt12ch31s04.html Normal file
View File

@ -0,0 +1,97 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Design</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; parallel&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="parallel_mode.html" title="Chapter 31. Parallel Mode" /><link rel="prev" href="bk01pt12ch31s03.html" title="Using" /><link rel="next" href="bk01pt12ch31s05.html" title="Testing" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Design</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch31s03.html">Prev</a> </td><th width="60%" align="center">Chapter 31. Parallel Mode</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch31s05.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.parallel_mode.design"></a>Design</h2></div></div></div><p>
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.parallel_mode.design.intro"></a>Interface Basics</h3></div></div></div><p>All parallel algorithms are intended to have signatures that are
equivalent to the ISO C++ algorithms replaced. For instance, the
<code class="code">std::adjacent_find</code> function is declared as:
</p><pre class="programlisting">
namespace std
{
template&lt;typename _FIter&gt;
_FIter
adjacent_find(_FIter, _FIter);
}
</pre><p>
Which means that there should be something equivalent for the parallel
version. Indeed, this is the case:
</p><pre class="programlisting">
namespace std
{
namespace __parallel
{
template&lt;typename _FIter&gt;
_FIter
adjacent_find(_FIter, _FIter);
...
}
}
</pre><p>But.... why the elipses?
</p><p> The elipses in the example above represent additional overloads
required for the parallel version of the function. These additional
overloads are used to dispatch calls from the ISO C++ function
signature to the appropriate parallel function (or sequential
function, if no parallel functions are deemed worthy), based on either
compile-time or run-time conditions.
</p><p> Compile-time conditions are referred to as "embarrassingly
parallel," and are denoted with the appropriate dispatch object, ie
one of <code class="code">__gnu_parallel::sequential_tag</code>,
<code class="code">__gnu_parallel::parallel_tag</code>,
<code class="code">__gnu_parallel::balanced_tag</code>,
<code class="code">__gnu_parallel::unbalanced_tag</code>,
<code class="code">__gnu_parallel::omp_loop_tag</code>, or
<code class="code">__gnu_parallel::omp_loop_static_tag</code>.
</p><p> Run-time conditions depend on the hardware being used, the number
of threads available, etc., and are denoted by the use of the enum
<code class="code">__gnu_parallel::parallelism</code>. Values of this enum include
<code class="code">__gnu_parallel::sequential</code>,
<code class="code">__gnu_parallel::parallel_unbalanced</code>,
<code class="code">__gnu_parallel::parallel_balanced</code>,
<code class="code">__gnu_parallel::parallel_omp_loop</code>,
<code class="code">__gnu_parallel::parallel_omp_loop_static</code>, or
<code class="code">__gnu_parallel::parallel_taskqueue</code>.
</p><p> Putting all this together, the general view of overloads for the
parallel algorithms look like this:
</p><div class="itemizedlist"><ul type="disc"><li><p>ISO C++ signature</p></li><li><p>ISO C++ signature + sequential_tag argument</p></li><li><p>ISO C++ signature + parallelism argument</p></li></ul></div><p> Please note that the implementation may use additional functions
(designated with the <code class="code">_switch</code> suffix) to dispatch from the
ISO C++ signature to the correct parallel version. Also, some of the
algorithms do not have support for run-time conditions, so the last
overload is therefore missing.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.parallel_mode.design.tuning"></a>Configuration and Tuning</h3></div></div></div><p> Some algorithm variants can be enabled/disabled/selected at compile-time.
See <a class="ulink" href="latest-doxygen/compiletime__settings_8h.html" target="_top">
<code class="code">&lt;compiletime_settings.h&gt;</code></a> and
See <a class="ulink" href="latest-doxygen/compiletime__settings_8h.html" target="_top">
<code class="code">&lt;features.h&gt;</code></a> for details.
</p><p>
To specify the number of threads to be used for an algorithm,
use <code class="code">omp_set_num_threads</code>.
To force a function to execute sequentially,
even though parallelism is switched on in general,
add <code class="code">__gnu_parallel::sequential_tag()</code>
to the end of the argument list.
</p><p>
Parallelism always incurs some overhead. Thus, it is not
helpful to parallelize operations on very small sets of data.
There are measures to avoid parallelizing stuff that is not worth it.
For each algorithm, a minimum problem size can be stated,
usually using the variable
<code class="code">__gnu_parallel::Settings::[algorithm]_minimal_n</code>.
Please see <a class="ulink" href="latest-doxygen/settings_8h.html" target="_top">
<code class="code">&lt;settings.h&gt;</code></a> for details.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.parallel_mode.design.impl"></a>Implementation Namespaces</h3></div></div></div><p> One namespace contain versions of code that are explicitly sequential:
<code class="code">__gnu_serial</code>.
</p><p> Two namespaces contain the parallel mode:
<code class="code">std::__parallel</code> and <code class="code">__gnu_parallel</code>.
</p><p> Parallel implementations of standard components, including
template helpers to select parallelism, are defined in <code class="code">namespace
std::__parallel</code>. For instance, <code class="code">std::transform</code> from
&lt;algorithm&gt; has a parallel counterpart in
<code class="code">std::__parallel::transform</code> from
&lt;parallel/algorithm&gt;. In addition, these parallel
implementations are injected into <code class="code">namespace
__gnu_parallel</code> with using declarations.
</p><p> Support and general infrastructure is in <code class="code">namespace
__gnu_parallel</code>.
</p><p> More information, and an organized index of types and functions
related to the parallel mode on a per-namespace basis, can be found in
the generated source documentation.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch31s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="parallel_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch31s05.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Using </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Testing</td></tr></table></div></body></html>

26
libstdc++-v3/doc/html/manual/bk01pt12ch31s05.html Normal file
View File

@ -0,0 +1,26 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Testing</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; parallel&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="parallel_mode.html" title="Chapter 31. Parallel Mode" /><link rel="prev" href="bk01pt12ch31s04.html" title="Design" /><link rel="next" href="bk01pt12ch32.html" title="Chapter 32. Allocators" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Testing</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch31s04.html">Prev</a> </td><th width="60%" align="center">Chapter 31. Parallel Mode</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch32.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.parallel_mode.test"></a>Testing</h2></div></div></div><p>
Both the normal conformance and regression tests and the
supplemental performance tests work.
</p><p>
To run the conformance and regression tests with the parallel mode
active,
</p><pre class="screen">
<strong class="userinput"><code>make check-parallel</code></strong>
</pre><p>
The log and summary files for conformance testing are in the
<code class="code">testsuite/parallel</code> directory.
</p><p>
To run the performance tests with the parallel mode active,
</p><pre class="screen">
<strong class="userinput"><code>check-performance-parallel</code></strong>
</pre><p>
The result file for performance testing are in the
<code class="code">testsuite</code> directory, in the file
<code class="code">libstdc++_performance.sum</code>. In addition, the
policy-based containers have their own visualizations, which have
additional software dependencies than the usual bare-boned text
file, and can be generated by using the <code class="code">make
doc-performance</code> rule in the testsuite's Makefile.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch31s04.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="parallel_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch32.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Design </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 32. Allocators</td></tr></table></div></body></html>

394
libstdc++-v3/doc/html/manual/bk01pt12ch32.html Normal file
View File

@ -0,0 +1,394 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 32. Allocators</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII. Extensions" /><link rel="prev" href="bk01pt12ch31s05.html" title="Testing" /><link rel="next" href="bitmap_allocator.html" title="bitmap_allocator" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 32. Allocators</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch31s05.html">Prev</a> </td><th width="60%" align="center">Part XII. Extensions</th><td width="20%" align="right"> <a accesskey="n" href="bitmap_allocator.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.allocator"></a>Chapter 32. Allocators</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt12ch32.html#manual.ext.allocator.mt">mt_allocator</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch32.html#allocator.mt.intro">Intro</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch32.html#allocator.mt.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch32.html#allocator.mt.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch32.html#allocator.mt.example_single">Single Thread Example</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch32.html#allocator.mt.example_multi">Multiple Thread Example</a></span></dt></dl></dd><dt><span class="sect1"><a href="bitmap_allocator.html">bitmap_allocator</a></span></dt><dd><dl><dt><span class="sect2"><a href="bitmap_allocator.html#allocator.bitmap.design">Design</a></span></dt><dt><span class="sect2"><a href="bitmap_allocator.html#allocator.bitmap.impl">Implementation</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.allocator.mt"></a>mt_allocator</h2></div></div></div><p>
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.mt.intro"></a>Intro</h3></div></div></div><p>
The mt allocator [hereinafter referred to simply as "the allocator"]
is a fixed size (power of two) allocator that was initially
developed specifically to suit the needs of multi threaded
applications [hereinafter referred to as an MT application]. Over
time the allocator has evolved and been improved in many ways, in
particular it now also does a good job in single threaded
applications [hereinafter referred to as a ST application]. (Note:
In this document, when referring to single threaded applications
this also includes applications that are compiled with gcc without
thread support enabled. This is accomplished using ifdef's on
__GTHREADS). This allocator is tunable, very flexible, and capable
of high-performance.
</p><p>
The aim of this document is to describe - from an application point of
view - the "inner workings" of the allocator.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.mt.design_issues"></a>Design Issues</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="allocator.mt.overview"></a>Overview</h4></div></div></div><p> There are three general components to the allocator: a datum
describing the characteristics of the memory pool, a policy class
containing this pool that links instantiation types to common or
individual pools, and a class inheriting from the policy class that is
the actual allocator.
</p><p>The datum describing pools characteristics is
</p><pre class="programlisting">
template&lt;bool _Thread&gt;
class __pool
</pre><p> This class is parametrized on thread support, and is explicitly
specialized for both multiple threads (with <code class="code">bool==true</code>)
and single threads (via <code class="code">bool==false</code>.) It is possible to
use a custom pool datum instead of the default class that is provided.
</p><p> There are two distinct policy classes, each of which can be used
with either type of underlying pool datum.
</p><pre class="programlisting">
template&lt;bool _Thread&gt;
struct __common_pool_policy
template&lt;typename _Tp, bool _Thread&gt;
struct __per_type_pool_policy
</pre><p> The first policy, <code class="code">__common_pool_policy</code>, implements a
common pool. This means that allocators that are instantiated with
different types, say <code class="code">char</code> and <code class="code">long</code> will both
use the same pool. This is the default policy.
</p><p> The second policy, <code class="code">__per_type_pool_policy</code>, implements
a separate pool for each instantiating type. Thus, <code class="code">char</code>
and <code class="code">long</code> will use separate pools. This allows per-type
tuning, for instance.
</p><p> Putting this all together, the actual allocator class is
</p><pre class="programlisting">
template&lt;typename _Tp, typename _Poolp = __default_policy&gt;
class __mt_alloc : public __mt_alloc_base&lt;_Tp&gt;, _Poolp
</pre><p> This class has the interface required for standard library allocator
classes, namely member functions <code class="code">allocate</code> and
<code class="code">deallocate</code>, plus others.
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.mt.impl"></a>Implementation</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="allocator.mt.tune"></a>Tunable Parameters</h4></div></div></div><p>Certain allocation parameters can be modified, or tuned. There
exists a nested <code class="code">struct __pool_base::_Tune</code> that contains all
these parameters, which include settings for
</p><div class="itemizedlist"><ul type="disc"><li><p>Alignment</p></li><li><p>Maximum bytes before calling <code class="code">::operator new</code> directly</p></li><li><p>Minimum bytes</p></li><li><p>Size of underlying global allocations</p></li><li><p>Maximum number of supported threads</p></li><li><p>Migration of deallocations to the global free list</p></li><li><p>Shunt for global <code class="code">new</code> and <code class="code">delete</code></p></li></ul></div><p>Adjusting parameters for a given instance of an allocator can only
happen before any allocations take place, when the allocator itself is
initialized. For instance:
</p><pre class="programlisting">
#include &lt;ext/mt_allocator.h&gt;
struct pod
{
int i;
int j;
};
int main()
{
typedef pod value_type;
typedef __gnu_cxx::__mt_alloc&lt;value_type&gt; allocator_type;
typedef __gnu_cxx::__pool_base::_Tune tune_type;
tune_type t_default;
tune_type t_opt(16, 5120, 32, 5120, 20, 10, false);
tune_type t_single(16, 5120, 32, 5120, 1, 10, false);
tune_type t;
t = allocator_type::_M_get_options();
allocator_type::_M_set_options(t_opt);
t = allocator_type::_M_get_options();
allocator_type a;
allocator_type::pointer p1 = a.allocate(128);
allocator_type::pointer p2 = a.allocate(5128);
a.deallocate(p1, 128);
a.deallocate(p2, 5128);
return 0;
}
</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="allocator.mt.init"></a>Initialization</h4></div></div></div><p>
The static variables (pointers to freelists, tuning parameters etc)
are initialized as above, or are set to the global defaults.
</p><p>
The very first allocate() call will always call the
_S_initialize_once() function. In order to make sure that this
function is called exactly once we make use of a __gthread_once call
in MT applications and check a static bool (_S_init) in ST
applications.
</p><p>
The _S_initialize() function:
- If the GLIBCXX_FORCE_NEW environment variable is set, it sets the bool
_S_force_new to true and then returns. This will cause subsequent calls to
allocate() to return memory directly from a new() call, and deallocate will
only do a delete() call.
</p><p>
- If the GLIBCXX_FORCE_NEW environment variable is not set, both ST and MT
applications will:
- Calculate the number of bins needed. A bin is a specific power of two size
of bytes. I.e., by default the allocator will deal with requests of up to
128 bytes (or whatever the value of _S_max_bytes is when _S_init() is
called). This means that there will be bins of the following sizes
(in bytes): 1, 2, 4, 8, 16, 32, 64, 128.
- Create the _S_binmap array. All requests are rounded up to the next
"large enough" bin. I.e., a request for 29 bytes will cause a block from
the "32 byte bin" to be returned to the application. The purpose of
_S_binmap is to speed up the process of finding out which bin to use.
I.e., the value of _S_binmap[ 29 ] is initialized to 5 (bin 5 = 32 bytes).
</p><p>
- Create the _S_bin array. This array consists of bin_records. There will be
as many bin_records in this array as the number of bins that we calculated
earlier. I.e., if _S_max_bytes = 128 there will be 8 entries.
Each bin_record is then initialized:
- bin_record-&gt;first = An array of pointers to block_records. There will be
as many block_records pointers as there are maximum number of threads
(in a ST application there is only 1 thread, in a MT application there
are _S_max_threads).
This holds the pointer to the first free block for each thread in this
bin. I.e., if we would like to know where the first free block of size 32
for thread number 3 is we would look this up by: _S_bin[ 5 ].first[ 3 ]
The above created block_record pointers members are now initialized to
their initial values. I.e. _S_bin[ n ].first[ n ] = NULL;
</p><p>
- Additionally a MT application will:
- Create a list of free thread id's. The pointer to the first entry
is stored in _S_thread_freelist_first. The reason for this approach is
that the __gthread_self() call will not return a value that corresponds to
the maximum number of threads allowed but rather a process id number or
something else. So what we do is that we create a list of thread_records.
This list is _S_max_threads long and each entry holds a size_t thread_id
which is initialized to 1, 2, 3, 4, 5 and so on up to _S_max_threads.
Each time a thread calls allocate() or deallocate() we call
_S_get_thread_id() which looks at the value of _S_thread_key which is a
thread local storage pointer. If this is NULL we know that this is a newly
created thread and we pop the first entry from this list and saves the
pointer to this record in the _S_thread_key variable. The next time
we will get the pointer to the thread_record back and we use the
thread_record-&gt;thread_id as identification. I.e., the first thread that
calls allocate will get the first record in this list and thus be thread
number 1 and will then find the pointer to its first free 32 byte block
in _S_bin[ 5 ].first[ 1 ]
When we create the _S_thread_key we also define a destructor
(_S_thread_key_destr) which means that when the thread dies, this
thread_record is returned to the front of this list and the thread id
can then be reused if a new thread is created.
This list is protected by a mutex (_S_thread_freelist_mutex) which is only
locked when records are removed or added to the list.
</p><p>
- Initialize the free and used counters of each bin_record:
- bin_record-&gt;free = An array of size_t. This keeps track of the number
of blocks on a specific thread's freelist in each bin. I.e., if a thread
has 12 32-byte blocks on it's freelists and allocates one of these, this
counter would be decreased to 11.
- bin_record-&gt;used = An array of size_t. This keeps track of the number
of blocks currently in use of this size by this thread. I.e., if a thread
has made 678 requests (and no deallocations...) of 32-byte blocks this
counter will read 678.
The above created arrays are now initialized with their initial values.
I.e. _S_bin[ n ].free[ n ] = 0;
</p><p>
- Initialize the mutex of each bin_record: The bin_record-&gt;mutex
is used to protect the global freelist. This concept of a global
freelist is explained in more detail in the section "A multi
threaded example", but basically this mutex is locked whenever a
block of memory is retrieved or returned to the global freelist
for this specific bin. This only occurs when a number of blocks
are grabbed from the global list to a thread specific list or when
a thread decides to return some blocks to the global freelist.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="allocator.mt.deallocation"></a>Deallocation Notes</h4></div></div></div><p> Notes about deallocation. This allocator does not explicitly
release memory. Because of this, memory debugging programs like
valgrind or purify may notice leaks: sorry about this
inconvenience. Operating systems will reclaim allocated memory at
program termination anyway. If sidestepping this kind of noise is
desired, there are three options: use an allocator, like
<code class="code">new_allocator</code> that releases memory while debugging, use
GLIBCXX_FORCE_NEW to bypass the allocator's internal pools, or use a
custom pool datum that releases resources on destruction.
</p><p>
On systems with the function <code class="code">__cxa_atexit</code>, the
allocator can be forced to free all memory allocated before program
termination with the member function
<code class="code">__pool_type::_M_destroy</code>. However, because this member
function relies on the precise and exactly-conforming ordering of
static destructors, including those of a static local
<code class="code">__pool</code> object, it should not be used, ever, on systems
that don't have the necessary underlying support. In addition, in
practice, forcing deallocation can be tricky, as it requires the
<code class="code">__pool</code> object to be fully-constructed before the object
that uses it is fully constructed. For most (but not all) STL
containers, this works, as an instance of the allocator is constructed
as part of a container's constructor. However, this assumption is
implementation-specific, and subject to change. For an example of a
pool that frees memory, see the following
<a class="ulink" href="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/ext/mt_allocator/deallocate_local-6.cc?view=markup" target="_top">
example.</a>
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.mt.example_single"></a>Single Thread Example</h3></div></div></div><p>
Let's start by describing how the data on a freelist is laid out in memory.
This is the first two blocks in freelist for thread id 3 in bin 3 (8 bytes):
</p><pre class="programlisting">
+----------------+
| next* ---------|--+ (_S_bin[ 3 ].first[ 3 ] points here)
| | |
| | |
| | |
+----------------+ |
| thread_id = 3 | |
| | |
| | |
| | |
+----------------+ |
| DATA | | (A pointer to here is what is returned to the
| | | the application when needed)
| | |
| | |
| | |
| | |
| | |
| | |
+----------------+ |
+----------------+ |
| next* |&lt;-+ (If next == NULL it's the last one on the list)
| |
| |
| |
+----------------+
| thread_id = 3 |
| |
| |
| |
+----------------+
| DATA |
| |
| |
| |
| |
| |
| |
| |
+----------------+
</pre><p>
With this in mind we simplify things a bit for a while and say that there is
only one thread (a ST application). In this case all operations are made to
what is referred to as the global pool - thread id 0 (No thread may be
assigned this id since they span from 1 to _S_max_threads in a MT application).
</p><p>
When the application requests memory (calling allocate()) we first look at the
requested size and if this is &gt; _S_max_bytes we call new() directly and return.
</p><p>
If the requested size is within limits we start by finding out from which
bin we should serve this request by looking in _S_binmap.
</p><p>
A quick look at _S_bin[ bin ].first[ 0 ] tells us if there are any blocks of
this size on the freelist (0). If this is not NULL - fine, just remove the
block that _S_bin[ bin ].first[ 0 ] points to from the list,
update _S_bin[ bin ].first[ 0 ] and return a pointer to that blocks data.
</p><p>
If the freelist is empty (the pointer is NULL) we must get memory from the
system and build us a freelist within this memory. All requests for new memory
is made in chunks of _S_chunk_size. Knowing the size of a block_record and
the bytes that this bin stores we then calculate how many blocks we can create
within this chunk, build the list, remove the first block, update the pointer
(_S_bin[ bin ].first[ 0 ]) and return a pointer to that blocks data.
</p><p>
Deallocation is equally simple; the pointer is casted back to a block_record
pointer, lookup which bin to use based on the size, add the block to the front
of the global freelist and update the pointer as needed
(_S_bin[ bin ].first[ 0 ]).
</p><p>
The decision to add deallocated blocks to the front of the freelist was made
after a set of performance measurements that showed that this is roughly 10%
faster than maintaining a set of "last pointers" as well.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.mt.example_multi"></a>Multiple Thread Example</h3></div></div></div><p>
In the ST example we never used the thread_id variable present in each block.
Let's start by explaining the purpose of this in a MT application.
</p><p>
The concept of "ownership" was introduced since many MT applications
allocate and deallocate memory to shared containers from different
threads (such as a cache shared amongst all threads). This introduces
a problem if the allocator only returns memory to the current threads
freelist (I.e., there might be one thread doing all the allocation and
thus obtaining ever more memory from the system and another thread
that is getting a longer and longer freelist - this will in the end
consume all available memory).
</p><p>
Each time a block is moved from the global list (where ownership is
irrelevant), to a threads freelist (or when a new freelist is built
from a chunk directly onto a threads freelist or when a deallocation
occurs on a block which was not allocated by the same thread id as the
one doing the deallocation) the thread id is set to the current one.
</p><p>
What's the use? Well, when a deallocation occurs we can now look at
the thread id and find out if it was allocated by another thread id
and decrease the used counter of that thread instead, thus keeping the
free and used counters correct. And keeping the free and used counters
corrects is very important since the relationship between these two
variables decides if memory should be returned to the global pool or
not when a deallocation occurs.
</p><p>
When the application requests memory (calling allocate()) we first
look at the requested size and if this is &gt;_S_max_bytes we call new()
directly and return.
</p><p>
If the requested size is within limits we start by finding out from which
bin we should serve this request by looking in _S_binmap.
</p><p>
A call to _S_get_thread_id() returns the thread id for the calling thread
(and if no value has been set in _S_thread_key, a new id is assigned and
returned).
</p><p>
A quick look at _S_bin[ bin ].first[ thread_id ] tells us if there are
any blocks of this size on the current threads freelist. If this is
not NULL - fine, just remove the block that _S_bin[ bin ].first[
thread_id ] points to from the list, update _S_bin[ bin ].first[
thread_id ], update the free and used counters and return a pointer to
that blocks data.
</p><p>
If the freelist is empty (the pointer is NULL) we start by looking at
the global freelist (0). If there are blocks available on the global
freelist we lock this bins mutex and move up to block_count (the
number of blocks of this bins size that will fit into a _S_chunk_size)
or until end of list - whatever comes first - to the current threads
freelist and at the same time change the thread_id ownership and
update the counters and pointers. When the bins mutex has been
unlocked, we remove the block that _S_bin[ bin ].first[ thread_id ]
points to from the list, update _S_bin[ bin ].first[ thread_id ],
update the free and used counters, and return a pointer to that blocks
data.
</p><p>
The reason that the number of blocks moved to the current threads
freelist is limited to block_count is to minimize the chance that a
subsequent deallocate() call will return the excess blocks to the
global freelist (based on the _S_freelist_headroom calculation, see
below).
</p><p>
However if there isn't any memory on the global pool we need to get
memory from the system - this is done in exactly the same way as in a
single threaded application with one major difference; the list built
in the newly allocated memory (of _S_chunk_size size) is added to the
current threads freelist instead of to the global.
</p><p>
The basic process of a deallocation call is simple: always add the
block to the front of the current threads freelist and update the
counters and pointers (as described earlier with the specific check of
ownership that causes the used counter of the thread that originally
allocated the block to be decreased instead of the current threads
counter).
</p><p>
And here comes the free and used counters to service. Each time a
deallocation() call is made, the length of the current threads
freelist is compared to the amount memory in use by this thread.
</p><p>
Let's go back to the example of an application that has one thread
that does all the allocations and one that deallocates. Both these
threads use say 516 32-byte blocks that was allocated during thread
creation for example. Their used counters will both say 516 at this
point. The allocation thread now grabs 1000 32-byte blocks and puts
them in a shared container. The used counter for this thread is now
1516.
</p><p>
The deallocation thread now deallocates 500 of these blocks. For each
deallocation made the used counter of the allocating thread is
decreased and the freelist of the deallocation thread gets longer and
longer. But the calculation made in deallocate() will limit the length
of the freelist in the deallocation thread to _S_freelist_headroom %
of it's used counter. In this case, when the freelist (given that the
_S_freelist_headroom is at it's default value of 10%) exceeds 52
(516/10) blocks will be returned to the global pool where the
allocating thread may pick them up and reuse them.
</p><p>
In order to reduce lock contention (since this requires this bins
mutex to be locked) this operation is also made in chunks of blocks
(just like when chunks of blocks are moved from the global freelist to
a threads freelist mentioned above). The "formula" used can probably
be improved to further reduce the risk of blocks being "bounced back
and forth" between freelists.
</p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch31s05.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bitmap_allocator.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Testing </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> bitmap_allocator</td></tr></table></div></body></html>

6
libstdc++-v3/doc/html/manual/bk01pt12ch33.html Normal file
View File

@ -0,0 +1,6 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 33. Containers</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII. Extensions" /><link rel="prev" href="bitmap_allocator.html" title="bitmap_allocator" /><link rel="next" href="bk01pt12ch33s02.html" title="HP/SGI" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 33. Containers</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bitmap_allocator.html">Prev</a> </td><th width="60%" align="center">Part XII. Extensions</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch33s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.containers"></a>Chapter 33. Containers</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt12ch33.html#manual.ext.containers.pbds">Policy Based Data Structures</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch33s02.html">HP/SGI</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch33s03.html">Deprecated HP/SGI</a></span></dt></dl></div><p>
</p><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.containers.pbds"></a>Policy Based Data Structures</h2></div></div></div><p>
<a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/ext/pb_ds/index.html" target="_top">More details here</a>.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bitmap_allocator.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch33s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">bitmap_allocator </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> HP/SGI</td></tr></table></div></body></html>

43
libstdc++-v3/doc/html/manual/bk01pt12ch33s02.html Normal file
View File

@ -0,0 +1,43 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>HP/SGI</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt12ch33.html" title="Chapter 33. Containers" /><link rel="prev" href="bk01pt12ch33.html" title="Chapter 33. Containers" /><link rel="next" href="bk01pt12ch33s03.html" title="Deprecated HP/SGI" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">HP/SGI</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch33.html">Prev</a> </td><th width="60%" align="center">Chapter 33. Containers</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch33s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.containers.sgi"></a>HP/SGI</h2></div></div></div><p>
</p><p>A few extensions and nods to backwards-compatibility 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 class="code">bit_vector</code> class is present for
backwards compatibility. It is simply a typedef for the
<code class="code">vector&lt;bool&gt;</code> specialization.
</p><p>The <code class="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 class="code">bitset&lt;N&gt;</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 (&lt;=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&lt;N&gt;," then their names and signatures are:
</p><pre class="programlisting">
bitset&lt;N&gt;&amp; _Unchecked_set (size_t pos);
bitset&lt;N&gt;&amp; _Unchecked_set (size_t pos, int val);
bitset&lt;N&gt;&amp; _Unchecked_reset (size_t pos);
bitset&lt;N&gt;&amp; _Unchecked_flip (size_t pos);
bool _Unchecked_test (size_t pos);
</pre><p>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 class="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 class="code">op[]</code>
on a const bitset returns a bool, and for a non-const bitset returns a
<code class="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 class="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 class="code">prev</code>, respectively:
</p><pre class="programlisting">
size_t _Find_first() const;
size_t _Find_next (size_t prev) const;</pre><p>The same caveat given for the _Unchecked_* functions applies here also.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch33.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt12ch33.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch33s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 33. Containers </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Deprecated HP/SGI</td></tr></table></div></body></html>

50
libstdc++-v3/doc/html/manual/bk01pt12ch33s03.html Normal file
View File

@ -0,0 +1,50 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Deprecated HP/SGI</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt12ch33.html" title="Chapter 33. Containers" /><link rel="prev" href="bk01pt12ch33s02.html" title="HP/SGI" /><link rel="next" href="bk01pt12ch34.html" title="Chapter 34. Utilities" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Deprecated HP/SGI</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch33s02.html">Prev</a> </td><th width="60%" align="center">Chapter 33. Containers</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch34.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.containers.deprecated_sgi"></a>Deprecated HP/SGI</h2></div></div></div><p>
The SGI hashing classes <code class="classname">hash_set</code> and
<code class="classname">hash_set</code> have been deprecated by the
unordered_set, unordered_multiset, unordered_map,
unordered_multimap containers in TR1 and the upcoming C++0x, and
may be removed in future releases.
</p><p>The SGI headers</p><pre class="programlisting">
&lt;hash_map&gt;
&lt;hash_set&gt;
&lt;rope&gt;
&lt;slist&gt;
&lt;rb_tree&gt;
</pre><p>are all here;
<code class="code">&lt;hash_map&gt;</code> and <code class="code">&lt;hash_set&gt;</code>
are deprecated but available as backwards-compatible extensions,
as discussed further below. <code class="code">&lt;rope&gt;</code> is the
SGI specialization for large strings ("rope,"
"large strings," get it? Love that geeky humor.)
<code class="code">&lt;slist&gt;</code> is a singly-linked list, for when the
doubly-linked <code class="code">list&lt;&gt;</code> is too much space
overhead, and <code class="code">&lt;rb_tree&gt;</code> exposes the red-black
tree classes used in the implementation of the standard maps and
sets.
</p><p>Each of the associative containers map, multimap, set, and multiset
have a counterpart which uses a
<a class="ulink" href="http://www.sgi.com/tech/stl/HashFunction.html" target="_top">hashing
function</a> to do the arranging, instead of a strict weak ordering
function. The classes take as one of their template parameters a
function object that will return the hash value; by default, an
instantiation of
<a class="ulink" href="http://www.sgi.com/tech/stl/hash.html" target="_top">hash</a>.
You should specialize this functor for your class, or define your own,
before trying to use one of the hashing classes.
</p><p>The hashing classes support all the usual associative container
functions, as well as some extra constructors specifying the number
of buckets, etc.
</p><p>Why would you want to use a hashing class instead of the
“<span class="quote">normal</span>”implementations? Matt Austern writes:
</p><div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em>[W]ith a well chosen hash function, hash tables
generally provide much better average-case performance than
binary search trees, and much worse worst-case performance. So
if your implementation has hash_map, if you don't mind using
nonstandard components, and if you aren't scared about the
possibility of pathological cases, you'll probably get better
performance from hash_map.
</em></span>
</p></blockquote></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch33s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt12ch33.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch34.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">HP/SGI </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 34. Utilities</td></tr></table></div></body></html>

38
libstdc++-v3/doc/html/manual/bk01pt12ch34.html Normal file
View File

@ -0,0 +1,38 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 34. Utilities</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII. Extensions" /><link rel="prev" href="bk01pt12ch33s03.html" title="Deprecated HP/SGI" /><link rel="next" href="bk01pt12ch35.html" title="Chapter 35. Algorithms" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 34. Utilities</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch33s03.html">Prev</a> </td><th width="60%" align="center">Part XII. Extensions</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch35.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.util"></a>Chapter 34. Utilities</h2></div></div></div><p>
The &lt;functional&gt; header contains many additional functors
and helper functions, extending section 20.3. They are
implemented in the file stl_function.h:
</p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">identity_element</code> for addition and multiplication. *
</p></li><li><p>The functor <code class="code">identity</code>, whose <code class="code">operator()</code>
returns the argument unchanged. *
</p></li><li><p>Composition functors <code class="code">unary_function</code> and
<code class="code">binary_function</code>, and their helpers <code class="code">compose1</code>
and <code class="code">compose2</code>. *
</p></li><li><p><code class="code">select1st</code> and <code class="code">select2nd</code>, to strip pairs. *
</p></li><li><p><code class="code">project1st</code> and <code class="code">project2nd</code>. * </p></li><li><p>A set of functors/functions which always return the same result. They
are <code class="code">constant_void_fun</code>, <code class="code">constant_binary_fun</code>,
<code class="code">constant_unary_fun</code>, <code class="code">constant0</code>,
<code class="code">constant1</code>, and <code class="code">constant2</code>. * </p></li><li><p>The class <code class="code">subtractive_rng</code>. * </p></li><li><p>mem_fun adaptor helpers <code class="code">mem_fun1</code> and
<code class="code">mem_fun1_ref</code> are provided for backwards compatibility. </p></li></ul></div><p>
20.4.1 can use several different allocators; they are described on the
main extensions page.
</p><p>
20.4.3 is extended with a special version of
<code class="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
</p><pre class="programlisting">
get_temporary_buffer&lt;int&gt;(5);
</pre><p>
you can also use
</p><pre class="programlisting">
get_temporary_buffer(5, (int*)0);
</pre><p>
A class <code 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 class="code">uninitialized_copy_n</code>. *
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch33s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch35.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Deprecated HP/SGI </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 35. Algorithms</td></tr></table></div></body></html>

20
libstdc++-v3/doc/html/manual/bk01pt12ch35.html Normal file
View File

@ -0,0 +1,20 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 35. Algorithms</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII. Extensions" /><link rel="prev" href="bk01pt12ch34.html" title="Chapter 34. Utilities" /><link rel="next" href="bk01pt12ch36.html" title="Chapter 36. Numerics" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 35. Algorithms</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch34.html">Prev</a> </td><th width="60%" align="center">Part XII. Extensions</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch36.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.algorithms"></a>Chapter 35. Algorithms</h2></div></div></div><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.,
</p><pre class="programlisting">
void count (first, last, value, n);</pre><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
</p><pre class="programlisting">
copy_n (_InputIter first, _Size count, _OutputIter result);</pre><p>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.
</p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">is_heap</code> tests whether or not a range is a heap.</p></li><li><p><code class="code">is_sorted</code> tests whether or not a range is sorted in
nondescending order.</p></li></ul></div><p>25.3.8 (lexigraphical_compare) is extended with
</p><pre class="programlisting">
lexicographical_compare_3way(_InputIter1 first1, _InputIter1 last1,
_InputIter2 first2, _InputIter2 last2)</pre><p>which does... what?
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch34.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch36.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 34. Utilities </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 36. Numerics</td></tr></table></div></body></html>

17
libstdc++-v3/doc/html/manual/bk01pt12ch36.html Normal file
View File

@ -0,0 +1,17 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 36. Numerics</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII. Extensions" /><link rel="prev" href="bk01pt12ch35.html" title="Chapter 35. Algorithms" /><link rel="next" href="bk01pt12ch37.html" title="Chapter 37. Iterators" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 36. Numerics</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch35.html">Prev</a> </td><th width="60%" align="center">Part XII. Extensions</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch37.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.numerics"></a>Chapter 36. Numerics</h2></div></div></div><p>26.4, the generalized numeric operations such as accumulate, are extended
with the following functions:
</p><pre class="programlisting">
power (x, n);
power (x, n, moniod_operation);</pre><p>Returns, in FORTRAN syntax, "x ** n" where n&gt;=0. In the
case of n == 0, returns the <a class="ulink" href="#ch20" target="_top">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 class="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.
</p><pre class="programlisting">
void iota(_ForwardIter first, _ForwardIter last, _Tp value);</pre></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch35.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch37.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 35. Algorithms </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 37. Iterators</td></tr></table></div></body></html>

11
libstdc++-v3/doc/html/manual/bk01pt12ch37.html Normal file
View File

@ -0,0 +1,11 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 37. Iterators</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII. Extensions" /><link rel="prev" href="bk01pt12ch36.html" title="Chapter 36. Numerics" /><link rel="next" href="bk01pt12ch38.html" title="Chapter 38. Input and Output" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 37. Iterators</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch36.html">Prev</a> </td><th width="60%" align="center">Part XII. Extensions</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch38.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.iterators"></a>Chapter 37. Iterators</h2></div></div></div><p>24.3.2 describes <code class="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:
</p><div class="itemizedlist"><ul type="disc"><li><p>input_iterator</p></li><li><p>output_iterator</p></li><li><p>forward_iterator</p></li><li><p>bidirectional_iterator</p></li><li><p>random_access_iterator</p></li></ul></div><p>24.3.4 describes iterator operation <code class="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></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch36.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch38.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 36. Numerics </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 38. Input and Output</td></tr></table></div></body></html>

48
libstdc++-v3/doc/html/manual/bk01pt12ch38.html Normal file
View File

@ -0,0 +1,48 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 38. Input and Output</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII. Extensions" /><link rel="prev" href="bk01pt12ch37.html" title="Chapter 37. Iterators" /><link rel="next" href="bk01pt12ch39.html" title="Chapter 39. Demangling" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 38. Input and Output</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch37.html">Prev</a> </td><th width="60%" align="center">Part XII. Extensions</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch39.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.io"></a>Chapter 38. Input and Output</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt12ch38.html#manual.ext.io.filebuf_derived">Derived filebufs</a></span></dt></dl></div><p>
Extensions allowing <code class="code">filebuf</code>s to be constructed from
"C" types like FILE*s and file descriptors.
</p><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.io.filebuf_derived"></a>Derived filebufs</h2></div></div></div><p>The v2 library included non-standard extensions to construct
<code class="code">std::filebuf</code>s from C stdio types such as
<code class="code">FILE*</code>s and POSIX file descriptors.
Today the recommended way to use stdio types with libstdc++
IOStreams is via the <code class="code">stdio_filebuf</code> class (see below),
but earlier releases provided slightly different mechanisms.
</p><div class="itemizedlist"><ul type="disc"><li><p>3.0.x <code class="code">filebuf</code>s have another ctor with this signature:
<code class="code">basic_filebuf(__c_file_type*, ios_base::openmode, int_type);
</code>
This comes in very handy in a number of places, such as
attaching Unix sockets, pipes, and anything else which uses file
descriptors, into the IOStream buffering classes. The three
arguments are as follows:
</p><div class="itemizedlist"><ul type="circle"><li><p><code class="code">__c_file_type* F </code>
// the __c_file_type typedef usually boils down to stdio's FILE
</p></li><li><p><code class="code">ios_base::openmode M </code>
// same as all the other uses of openmode
</p></li><li><p><code class="code">int_type B </code>
// buffer size, defaults to BUFSIZ if not specified
</p></li></ul></div><p>
For those wanting to use file descriptors instead of FILE*'s, I
invite you to contemplate the mysteries of C's <code class="code">fdopen()</code>.
</p></li><li><p>In library snapshot 3.0.95 and later, <code class="code">filebuf</code>s bring
back an old extension: the <code class="code">fd()</code> member function. The
integer returned from this function can be used for whatever file
descriptors can be used for on your platform. Naturally, the
library cannot track what you do on your own with a file descriptor,
so if you perform any I/O directly, don't expect the library to be
aware of it.
</p></li><li><p>Beginning with 3.1, the extra <code class="code">filebuf</code> constructor and
the <code class="code">fd()</code> function were removed from the standard
filebuf. Instead, <code class="code">&lt;ext/stdio_filebuf.h&gt;</code> contains
a derived class called
<a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/class____gnu__cxx_1_1stdio__filebuf.html" target="_top"><code class="code">__gnu_cxx::stdio_filebuf</code></a>.
This class can be constructed from a C <code class="code">FILE*</code> or a file
descriptor, and provides the <code class="code">fd()</code> function.
</p></li></ul></div><p>If you want to access a <code class="code">filebuf</code>'s file descriptor to
implement file locking (e.g. using the <code class="code">fcntl()</code> system
call) then you might be interested in Henry Suter's
<a class="ulink" href="http://suter.home.cern.ch/suter/RWLock.html" target="_top">RWLock</a>
class.
</p><p>
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch37.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch39.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 37. Iterators </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 39. Demangling</td></tr></table></div></body></html>

71
libstdc++-v3/doc/html/manual/bk01pt12ch39.html Normal file
View File

@ -0,0 +1,71 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 39. Demangling</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII. Extensions" /><link rel="prev" href="bk01pt12ch38.html" title="Chapter 38. Input and Output" /><link rel="next" href="concurrency.html" title="Chapter 40. Concurrency" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 39. Demangling</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch38.html">Prev</a> </td><th width="60%" align="center">Part XII. Extensions</th><td width="20%" align="right"> <a accesskey="n" href="concurrency.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.demangle"></a>Chapter 39. Demangling</h2></div></div></div><p>
Transforming C++ ABI itentifiers (like RTTI symbols) into the
original C++ source identifiers is called
“<span class="quote">demangling.</span>”
</p><p>
If you have read the <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/namespaceabi.html" target="_top">source
documentation for <code class="code">namespace abi</code></a> then you are
aware of the cross-vendor C++ ABI in use by GCC. One of the
exposed functions is used for demangling,
<code class="code">abi::__cxa_demangle</code>.
</p><p>
In programs like <span class="command"><strong>c++filt</strong></span>, the linker, and other tools
have the ability to decode C++ ABI names, and now so can you.
</p><p>
(The function itself might use different demanglers, but that's the
whole point of abstract interfaces. If we change the implementation,
you won't notice.)
</p><p>
Probably the only times you'll be interested in demangling at runtime
are when you're seeing <code class="code">typeid</code> strings in RTTI, or when
you're handling the runtime-support exception classes. For example:
</p><pre class="programlisting">
#include &lt;exception&gt;
#include &lt;iostream&gt;
#include &lt;cxxabi.h&gt;
struct empty { };
template &lt;typename T, int N&gt;
struct bar { };
int main()
{
int status;
char *realname;
// exception classes not in &lt;stdexcept&gt;, thrown by the implementation
// instead of the user
std::bad_exception e;
realname = abi::__cxa_demangle(e.what(), 0, 0, &amp;status);
std::cout &lt;&lt; e.what() &lt;&lt; "\t=&gt; " &lt;&lt; realname &lt;&lt; "\t: " &lt;&lt; status &lt;&lt; '\n';
free(realname);
// typeid
bar&lt;empty,17&gt; u;
const std::type_info &amp;ti = typeid(u);
realname = abi::__cxa_demangle(ti.name(), 0, 0, &amp;status);
std::cout &lt;&lt; ti.name() &lt;&lt; "\t=&gt; " &lt;&lt; realname &lt;&lt; "\t: " &lt;&lt; status &lt;&lt; '\n';
free(realname);
return 0;
}
</pre><p>
This prints
</p><pre class="screen">
<code class="computeroutput">
St13bad_exception =&gt; std::bad_exception : 0
3barI5emptyLi17EE =&gt; bar&lt;empty, 17&gt; : 0
</code>
</pre><p>
The demangler interface is described in the source documentation
linked to above. It is actually written in C, so you don't need to
be writing C++ in order to demangle C++. (That also means we have to
use crummy memory management facilities, so don't forget to free()
the returned char array.)
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch38.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="concurrency.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 38. Input and Output </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 40. Concurrency</td></tr></table></div></body></html>

38
libstdc++-v3/doc/html/manual/bk01pt12ch40s02.html Normal file
View File

@ -0,0 +1,38 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Implementation</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="concurrency.html" title="Chapter 40. Concurrency" /><link rel="prev" href="concurrency.html" title="Chapter 40. Concurrency" /><link rel="next" href="bk01pt12ch40s03.html" title="Use" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Implementation</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="concurrency.html">Prev</a> </td><th width="60%" align="center">Chapter 40. Concurrency</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch40s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.concurrency.impl"></a>Implementation</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.concurrency.impl.atomic_fallbacks"></a>Using Builitin Atomic Functions</h3></div></div></div><p>The functions for atomic operations described above are either
implemented via compiler intrinsics (if the underlying host is
capable) or by library fallbacks.</p><p>Compiler intrinsics (builtins) are always preferred. However, as
the compiler builtins for atomics are not universally implemented,
using them directly is problematic, and can result in undefined
function calls. (An example of an undefined symbol from the use
of <code class="code">__sync_fetch_and_add</code> on an unsupported host is a
missing reference to <code class="code">__sync_fetch_and_add_4</code>.)
</p><p>In addition, on some hosts the compiler intrinsics are enabled
conditionally, via the <code class="code">-march</code> command line flag. This makes
usage vary depending on the target hardware and the flags used during
compile.
</p><p> If builtins are possible, <code class="code">_GLIBCXX_ATOMIC_BUILTINS</code>
will be defined.
</p><p>For the following hosts, intrinsics are enabled by default.
</p><div class="itemizedlist"><ul type="disc"><li><p>alpha</p></li><li><p>ia64</p></li><li><p>powerpc</p></li><li><p>s390</p></li></ul></div><p>For others, some form of <code class="code">-march</code> may work. On
non-ancient x86 hardware, <code class="code">-march=native</code> usually does the
trick.</p><p> For hosts without compiler intrinsics, but with capable
hardware, hand-crafted assembly is selected. This is the case for the following hosts:
</p><div class="itemizedlist"><ul type="disc"><li><p>cris</p></li><li><p>hppa</p></li><li><p>i386</p></li><li><p>i486</p></li><li><p>m48k</p></li><li><p>mips</p></li><li><p>sparc</p></li></ul></div><p>And for the rest, a simulated atomic lock via pthreads.
</p><p> Detailed information about compiler intrinsics for atomic operations can be found in the GCC <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html" target="_top"> documentation</a>.
</p><p> More details on the library fallbacks from the porting <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/porting.html#Thread%20safety" target="_top">section</a>.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.concurrency.impl.thread"></a>Thread Abstraction</h3></div></div></div><p>A thin layer above IEEE 1003.1 (ie pthreads) is used to abstract
the thread interface for GCC. This layer is called "gthread," and is
comprised of one header file that wraps the host's default thread layer with
a POSIX-like interface.
</p><p> The file &lt;gthr-default.h&gt; points to the deduced wrapper for
the current host. In libstdc++ implementation files,
&lt;bits/gthr.h&gt; is used to select the proper gthreads file.
</p><p>Within libstdc++ sources, all calls to underlying thread functionality
use this layer. More detail as to the specific interface can be found in the source <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/gthr_8h-source.html" target="_top">documentation</a>.
</p><p>By design, the gthread layer is interoperable with the types,
functions, and usage found in the usual &lt;pthread.h&gt; file,
including <code class="code">pthread_t</code>, <code class="code">pthread_once_t</code>, <code class="code">pthread_create</code>,
etc.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="concurrency.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="concurrency.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch40s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 40. Concurrency </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Use</td></tr></table></div></body></html>

34
libstdc++-v3/doc/html/manual/bk01pt12ch40s03.html Normal file
View File

@ -0,0 +1,34 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Use</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="concurrency.html" title="Chapter 40. Concurrency" /><link rel="prev" href="bk01pt12ch40s02.html" title="Implementation" /><link rel="next" href="appendix_contributing.html" title="Appendix A. Contributing" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Use</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch40s02.html">Prev</a> </td><th width="60%" align="center">Chapter 40. Concurrency</th><td width="20%" align="right"> <a accesskey="n" href="appendix_contributing.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.concurrency.use"></a>Use</h2></div></div></div><p>Typical usage of the last two constructs is demonstrated as follows:
</p><pre class="programlisting">
#include &lt;ext/concurrence.h&gt;
namespace
{
__gnu_cxx::__mutex safe_base_mutex;
} // anonymous namespace
namespace other
{
void
foo()
{
__gnu_cxx::__scoped_lock sentry(safe_base_mutex);
for (int i = 0; i &lt; max; ++i)
{
_Safe_iterator_base* __old = __iter;
__iter = __iter-&lt;_M_next;
__old-&lt;_M_detach_single();
}
}
</pre><p>In this sample code, an anonymous namespace is used to keep
the <code class="code">__mutex</code> private to the compilation unit,
and <code class="code">__scoped_lock</code> is used to guard access to the critical
section within the for loop, locking the mutex on creation and freeing
the mutex as control moves out of this block.
</p><p>Several exception classes are used to keep track of
concurrence-related errors. These classes
are: <code class="code">__concurrence_lock_error</code>, <code class="code">__concurrence_unlock_error</code>, <code class="code">__concurrence_wait_error</code>,
and <code class="code">__concurrence_broadcast_error</code>.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch40s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="concurrency.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="appendix_contributing.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Implementation </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix A. Contributing</td></tr></table></div></body></html>

21
libstdc++-v3/doc/html/manual/bk01pt12pr03.html Normal file
View File

@ -0,0 +1,21 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII. Extensions" /><link rel="prev" href="extensions.html" title="Part XII. Extensions" /><link rel="next" href="bk01pt12ch29.html" title="Chapter 29. Compile Time Checks" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="extensions.html">Prev</a> </td><th width="60%" align="center">Part XII. Extensions</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch29.html">Next</a></td></tr></table><hr /></div><div class="preface" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="id516952"></a></h2></div></div></div><p>
Here we will make an attempt at describing the non-Standard extensions to
the library. Some of these are from SGI's STL, some of these are GNU's,
and some just seemed to appear on the doorstep.
</p><p><span class="emphasis"><em>Before</em></span> you leap in and use any of these
extensions, be aware of two things:
</p><div class="orderedlist"><ol type="1"><li><p>
Non-Standard means exactly that.
</p><p>
The behavior, and the very
existence, of these extensions may change with little or no
warning. (Ideally, the really good ones will appear in the next
revision of C++.) Also, other platforms, other compilers, other
versions of g++ or libstdc++ may not recognize these names, or
treat them differently, or...
</p></li><li><p>
You should know how to <a class="ulink" href="XXX" target="_top">access
these headers properly</a>.
</p></li></ol></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="extensions.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch29.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part XII. Extensions </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 29. Compile Time Checks</td></tr></table></div></body></html>

95
libstdc++-v3/doc/html/manual/build.html Normal file
View File

@ -0,0 +1,95 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Build</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; build&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt01ch02.html" title="Chapter 2. Setup" /><link rel="prev" href="bk01pt01ch02.html" title="Chapter 2. Setup" /><link rel="next" href="test.html" title="Test" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Build</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt01ch02.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Setup</th><td width="20%" align="right"> <a accesskey="n" href="test.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.setup.build"></a>Build</h2></div></div></div><p>
Because libstdc++ is part of GCC, the primary source for
installation instructions is
<a class="ulink" href="http://gcc.gnu.org/install/" target="_top">the GCC install page</a>.
Additional data is given here only where it applies to libstdc++.
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="build.prereq"></a>Prerequisites</h3></div></div></div><p>
The list of software needed to build the library is kept with the
rest of the compiler, at
<a class="ulink" href="http://gcc.gnu.org/install/prerequisites.html" target="_top">
http://gcc.gnu.org/install/prerequisites.html</a>. The same page
also lists the tools you will need if you wish to modify the source.
</p><p>As of GCC 4.0.1 the minimum version of binutils required to build
libstdc++ is <code class="code">2.15.90.0.1.1</code>. You can get snapshots
(as well as releases) of binutils from
<a class="ulink" href="ftp://sources.redhat.com/pub/binutils" target="_top">
ftp://sources.redhat.com/pub/binutils</a>.
Older releases of libstdc++ do not require such a recent version,
but to take full advantage of useful space-saving features and
bug-fixes you should use a recent binutils if possible.
The configure process will automatically detect and use these
features if the underlying support is present.
</p><p>
Finally, a few system-specific requirements:
</p><div class="variablelist"><dl><dt><span class="term">linux</span></dt><dd><p>
If gcc 3.1.0 or later on is being used on linux, an attempt
will be made to use "C" library functionality necessary for
C++ named locale support. For gcc 3.2.1 and later, this
means that glibc 2.2.5 or later is required and the "C"
library de_DE locale information must be installed.
</p><p>
Note however that the sanity checks involving the de_DE
locale are skipped when an explicit --enable-clocale=gnu
configure option is used: only the basic checks are carried
out, defending against misconfigurations.
</p><p>
If the 'gnu' locale model is being used, the following
locales are used and tested in the libstdc++ testsuites.
The first column is the name of the locale, the second is
the character set it is expected to use.
</p><pre class="programlisting">
de_DE ISO-8859-1
de_DE@euro ISO-8859-15
en_HK ISO-8859-1
en_PH ISO-8859-1
en_US ISO-8859-1
en_US.ISO-8859-1 ISO-8859-1
en_US.ISO-8859-15 ISO-8859-15
en_US.UTF-8 UTF-8
es_ES ISO-8859-1
es_MX ISO-8859-1
fr_FR ISO-8859-1
fr_FR@euro ISO-8859-15
is_IS UTF-8
it_IT ISO-8859-1
ja_JP.eucjp EUC-JP
se_NO.UTF-8 UTF-8
ta_IN UTF-8
zh_TW BIG5
</pre><p>Failure to have the underlying "C" library locale
information installed will mean that C++ named locales for the
above regions will not work: because of this, the libstdc++
testsuite will skip the named locale tests. If this isn't an
issue, don't worry about it. If named locales are needed, the
underlying locale information must be installed. Note that
rebuilding libstdc++ after the "C" locales are installed is not
necessary.
</p><p>
To install support for locales, do only one of the following:
</p><div class="itemizedlist"><ul type="disc"><li><p>install all locales</p><div class="itemizedlist"><ul type="circle"><li><p>with RedHat Linux:
</p><p> <code class="code"> export LC_ALL=C </code>
</p><p> <code class="code"> rpm -e glibc-common --nodeps </code>
</p><p>
<code class="code"> rpm -i --define "_install_langs all"
glibc-common-2.2.5-34.i386.rpm
</code>
</p></li><li><p>
Instructions for other operating systems solicited.
</p></li></ul></div></li><li><p>install just the necessary locales</p><div class="itemizedlist"><ul type="circle"><li><p>with Debian Linux:</p><p> Add the above list, as shown, to the file
<code class="code">/etc/locale.gen</code> </p><p> run <code class="code">/usr/sbin/locale-gen</code> </p></li><li><p>on most Unix-like operating systems:</p><p><code class="code"> localedef -i de_DE -f ISO-8859-1 de_DE </code></p><p>(repeat for each entry in the above list) </p></li><li><p>
Instructions for other operating systems solicited.
</p></li></ul></div></li></ul></div></dd></dl></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="build.configure"></a>Make</h3></div></div></div><p>If you have never done this before, you should read the basic
<a class="ulink" href="http://gcc.gnu.org/install/" target="_top">GCC Installation
Instructions</a> first. Read <span class="emphasis"><em>all of them</em></span>.
<span class="emphasis"><em>Twice.</em></span>
</p><p>When building libstdc++ you'll have to configure
the entire <span class="emphasis"><em>gccsrcdir</em></span> directory. The full list of libstdc++
specific configuration options, not dependent on the specific compiler
release being used, can be found <a class="ulink" href="configopts.html" target="_top">here</a>.
</p><p>Consider possibly using --enable-languages=c++ to save time by only
building the C++ language parts.
</p><pre class="programlisting">
cd <span class="emphasis"><em>gccbuilddir</em></span>
<span class="emphasis"><em>gccsrcdir</em></span>/configure --prefix=<span class="emphasis"><em>destdir</em></span> --other-opts...</pre></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt01ch02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt01ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="test.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 2. Setup </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Test</td></tr></table></div></body></html>

379
libstdc++-v3/doc/html/manual/codecvt.html Normal file
View File

@ -0,0 +1,379 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>codecvt</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; codecvt&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt06ch15.html" title="Chapter 15. Facets aka Categories" /><link rel="prev" href="bk01pt06ch15.html" title="Chapter 15. Facets aka Categories" /><link rel="next" href="messages.html" title="messages" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">codecvt</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt06ch15.html">Prev</a> </td><th width="60%" align="center">Chapter 15. Facets aka Categories</th><td width="20%" align="right"> <a accesskey="n" href="messages.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.localization.facet.codecvt"></a>codecvt</h2></div></div></div><p>
The standard class codecvt attempts to address conversions between
different character encoding schemes. In particular, the standard
attempts to detail conversions between the implementation-defined wide
characters (hereafter referred to as wchar_t) and the standard type
char that is so beloved in classic “<span class="quote">C</span>” (which can now be
referred to as narrow characters.) This document attempts to describe
how the GNU libstdc++ implementation deals with the conversion between
wide and narrow characters, and also presents a framework for dealing
with the huge number of other encodings that iconv can convert,
including Unicode and UTF8. Design issues and requirements are
addressed, and examples of correct usage for both the required
specializations for wide and narrow characters and the
implementation-provided extended functionality are given.
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.codecvt.req"></a>Requirements</h3></div></div></div><p>
Around page 425 of the C++ Standard, this charming heading comes into view:
</p><div class="blockquote"><blockquote class="blockquote"><p>
22.2.1.5 - Template class codecvt
</p></blockquote></div><p>
The text around the codecvt definition gives some clues:
</p><div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em>
-1- The class codecvt&lt;internT,externT,stateT&gt; is for use when
converting from one codeset to another, such as from wide characters
to multibyte characters, between wide character encodings such as
Unicode and EUC.
</em></span>
</p></blockquote></div><p>
Hmm. So, in some unspecified way, Unicode encodings and
translations between other character sets should be handled by this
class.
</p><div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em>
-2- The stateT argument selects the pair of codesets being mapped between.
</em></span>
</p></blockquote></div><p>
Ah ha! Another clue...
</p><div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em>
-3- The instantiations required in the Table ??
(lib.locale.category), namely codecvt&lt;wchar_t,char,mbstate_t&gt; and
codecvt&lt;char,char,mbstate_t&gt;, convert the implementation-defined
native character set. codecvt&lt;char,char,mbstate_t&gt; implements a
degenerate conversion; it does not convert at
all. codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
character sets for tiny and wide characters. Instantiations on
mbstate_t perform conversion between encodings known to the library
implementor. Other encodings can be converted by specializing on a
user-defined stateT type. The stateT object can contain any state that
is useful to communicate to or from the specialized do_convert member.
</em></span>
</p></blockquote></div><p>
At this point, a couple points become clear:
</p><p>
One: The standard clearly implies that attempts to add non-required
(yet useful and widely used) conversions need to do so through the
third template parameter, stateT.</p><p>
Two: The required conversions, by specifying mbstate_t as the third
template parameter, imply an implementation strategy that is mostly
(or wholly) based on the underlying C library, and the functions
mcsrtombs and wcsrtombs in particular.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.codecvt.design"></a>Design</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="codecvt.design.wchar_t_size"></a><span class="type">wchar_t</span> Size</h4></div></div></div><p>
The simple implementation detail of wchar_t's size seems to
repeatedly confound people. Many systems use a two byte,
unsigned integral type to represent wide characters, and use an
internal encoding of Unicode or UCS2. (See AIX, Microsoft NT,
Java, others.) Other systems, use a four byte, unsigned integral
type to represent wide characters, and use an internal encoding
of UCS4. (GNU/Linux systems using glibc, in particular.) The C
programming language (and thus C++) does not specify a specific
size for the type wchar_t.
</p><p>
Thus, portable C++ code cannot assume a byte size (or endianness) either.
</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="codecvt.design.unicode"></a>Support for Unicode</h4></div></div></div><p>
Probably the most frequently asked question about code conversion
is: "So dudes, what's the deal with Unicode strings?"
The dude part is optional, but apparently the usefulness of
Unicode strings is pretty widely appreciated. Sadly, this specific
encoding (And other useful encodings like UTF8, UCS4, ISO 8859-10,
etc etc etc) are not mentioned in the C++ standard.
</p><p>
A couple of comments:
</p><p>
The thought that all one needs to convert between two arbitrary
codesets is two types and some kind of state argument is
unfortunate. In particular, encodings may be stateless. The naming
of the third parameter as stateT is unfortunate, as what is really
needed is some kind of generalized type that accounts for the
issues that abstract encodings will need. The minimum information
that is required includes:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Identifiers for each of the codesets involved in the
conversion. For example, using the iconv family of functions
from the Single Unix Specification (what used to be called
X/Open) hosted on the GNU/Linux operating system allows
bi-directional mapping between far more than the following
tantalizing possibilities:
</p><p>
(An edited list taken from <code class="code">`iconv --list`</code> on a
Red Hat 6.2/Intel system:
</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">
8859_1, 8859_9, 10646-1:1993, 10646-1:1993/UCS4, ARABIC, ARABIC7,
ASCII, EUC-CN, EUC-JP, EUC-KR, EUC-TW, GREEK-CCIcode, GREEK, GREEK7-OLD,
GREEK7, GREEK8, HEBREW, ISO-8859-1, ISO-8859-2, ISO-8859-3,
ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8,
ISO-8859-9, ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14,
ISO-8859-15, ISO-10646, ISO-10646/UCS2, ISO-10646/UCS4,
ISO-10646/UTF-8, ISO-10646/UTF8, SHIFT-JIS, SHIFT_JIS, UCS-2, UCS-4,
UCS2, UCS4, UNICODE, UNICODEBIG, UNICODELIcodeLE, US-ASCII, US, UTF-8,
UTF-16, UTF8, UTF16).
</pre></blockquote></div><p>
For iconv-based implementations, string literals for each of the
encodings (ie. "UCS-2" and "UTF-8") are necessary,
although for other,
non-iconv implementations a table of enumerated values or some other
mechanism may be required.
</p></li><li><p>
Maximum length of the identifying string literal.
</p></li><li><p>
Some encodings require explicit endian-ness. As such, some kind
of endian marker or other byte-order marker will be necessary. See
"Footnotes for C/C++ developers" in Haible for more information on
UCS-2/Unicode endian issues. (Summary: big endian seems most likely,
however implementations, most notably Microsoft, vary.)
</p></li><li><p>
Types representing the conversion state, for conversions involving
the machinery in the "C" library, or the conversion descriptor, for
conversions using iconv (such as the type iconv_t.) Note that the
conversion descriptor encodes more information than a simple encoding
state type.
</p></li><li><p>
Conversion descriptors for both directions of encoding. (ie, both
UCS-2 to UTF-8 and UTF-8 to UCS-2.)
</p></li><li><p>
Something to indicate if the conversion requested if valid.
</p></li><li><p>
Something to represent if the conversion descriptors are valid.
</p></li><li><p>
Some way to enforce strict type checking on the internal and
external types. As part of this, the size of the internal and
external types will need to be known.
</p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="codecvt.design.issues"></a>Other Issues</h4></div></div></div><p>
In addition, multi-threaded and multi-locale environments also impact
the design and requirements for code conversions. In particular, they
affect the required specialization codecvt&lt;wchar_t, char, mbstate_t&gt;
when implemented using standard "C" functions.
</p><p>
Three problems arise, one big, one of medium importance, and one small.
</p><p>
First, the small: mcsrtombs and wcsrtombs may not be multithread-safe
on all systems required by the GNU tools. For GNU/Linux and glibc,
this is not an issue.
</p><p>
Of medium concern, in the grand scope of things, is that the functions
used to implement this specialization work on null-terminated
strings. Buffers, especially file buffers, may not be null-terminated,
thus giving conversions that end prematurely or are otherwise
incorrect. Yikes!
</p><p>
The last, and fundamental problem, is the assumption of a global
locale for all the "C" functions referenced above. For something like
C++ iostreams (where codecvt is explicitly used) the notion of
multiple locales is fundamental. In practice, most users may not run
into this limitation. However, as a quality of implementation issue,
the GNU C++ library would like to offer a solution that allows
multiple locales and or simultaneous usage with computationally
correct results. In short, libstdc++ is trying to offer, as an
option, a high-quality implementation, damn the additional complexity!
</p><p>
For the required specialization codecvt&lt;wchar_t, char, mbstate_t&gt; ,
conversions are made between the internal character set (always UCS4
on GNU/Linux) and whatever the currently selected locale for the
LC_CTYPE category implements.
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.codecvt.impl"></a>Implementation</h3></div></div></div><p>
The two required specializations are implemented as follows:
</p><p>
<code class="code">
codecvt&lt;char, char, mbstate_t&gt;
</code>
</p><p>
This is a degenerate (ie, does nothing) specialization. Implementing
this was a piece of cake.
</p><p>
<code class="code">
codecvt&lt;char, wchar_t, mbstate_t&gt;
</code>
</p><p>
This specialization, by specifying all the template parameters, pretty
much ties the hands of implementors. As such, the implementation is
straightforward, involving mcsrtombs for the conversions between char
to wchar_t and wcsrtombs for conversions between wchar_t and char.
</p><p>
Neither of these two required specializations deals with Unicode
characters. As such, libstdc++ implements a partial specialization
of the codecvt class with and iconv wrapper class, encoding_state as the
third template parameter.
</p><p>
This implementation should be standards conformant. First of all, the
standard explicitly points out that instantiations on the third
template parameter, stateT, are the proper way to implement
non-required conversions. Second of all, the standard says (in Chapter
17) that partial specializations of required classes are a-ok. Third
of all, the requirements for the stateT type elsewhere in the standard
(see 21.1.2 traits typedefs) only indicate that this type be copy
constructible.
</p><p>
As such, the type encoding_state is defined as a non-templatized, POD
type to be used as the third type of a codecvt instantiation. This
type is just a wrapper class for iconv, and provides an easy interface
to iconv functionality.
</p><p>
There are two constructors for encoding_state:
</p><p>
<code class="code">
encoding_state() : __in_desc(0), __out_desc(0)
</code>
</p><p>
This default constructor sets the internal encoding to some default
(currently UCS4) and the external encoding to whatever is returned by
nl_langinfo(CODESET).
</p><p>
<code class="code">
encoding_state(const char* __int, const char* __ext)
</code>
</p><p>
This constructor takes as parameters string literals that indicate the
desired internal and external encoding. There are no defaults for
either argument.
</p><p>
One of the issues with iconv is that the string literals identifying
conversions are not standardized. Because of this, the thought of
mandating and or enforcing some set of pre-determined valid
identifiers seems iffy: thus, a more practical (and non-migraine
inducing) strategy was implemented: end-users can specify any string
(subject to a pre-determined length qualifier, currently 32 bytes) for
encodings. It is up to the user to make sure that these strings are
valid on the target system.
</p><p>
<code class="code">
void
_M_init()
</code>
</p><p>
Strangely enough, this member function attempts to open conversion
descriptors for a given encoding_state object. If the conversion
descriptors are not valid, the conversion descriptors returned will
not be valid and the resulting calls to the codecvt conversion
functions will return error.
</p><p>
<code class="code">
bool
_M_good()
</code>
</p><p>
Provides a way to see if the given encoding_state object has been
properly initialized. If the string literals describing the desired
internal and external encoding are not valid, initialization will
fail, and this will return false. If the internal and external
encodings are valid, but iconv_open could not allocate conversion
descriptors, this will also return false. Otherwise, the object is
ready to convert and will return true.
</p><p>
<code class="code">
encoding_state(const encoding_state&amp;)
</code>
</p><p>
As iconv allocates memory and sets up conversion descriptors, the copy
constructor can only copy the member data pertaining to the internal
and external code conversions, and not the conversion descriptors
themselves.
</p><p>
Definitions for all the required codecvt member functions are provided
for this specialization, and usage of codecvt&lt;internal character type,
external character type, encoding_state&gt; is consistent with other
codecvt usage.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.codecvt.use"></a>Use</h3></div></div></div><p>A conversions involving string literal.</p><pre class="programlisting">
typedef codecvt_base::result result;
typedef unsigned short unicode_t;
typedef unicode_t int_type;
typedef char ext_type;
typedef encoding_state state_type;
typedef codecvt&lt;int_type, ext_type, state_type&gt; unicode_codecvt;
const ext_type* e_lit = "black pearl jasmine tea";
int size = strlen(e_lit);
int_type i_lit_base[24] =
{ 25088, 27648, 24832, 25344, 27392, 8192, 28672, 25856, 24832, 29184,
27648, 8192, 27136, 24832, 29440, 27904, 26880, 28160, 25856, 8192, 29696,
25856, 24832, 2560
};
const int_type* i_lit = i_lit_base;
const ext_type* efrom_next;
const int_type* ifrom_next;
ext_type* e_arr = new ext_type[size + 1];
ext_type* eto_next;
int_type* i_arr = new int_type[size + 1];
int_type* ito_next;
// construct a locale object with the specialized facet.
locale loc(locale::classic(), new unicode_codecvt);
// sanity check the constructed locale has the specialized facet.
VERIFY( has_facet&lt;unicode_codecvt&gt;(loc) );
const unicode_codecvt&amp; cvt = use_facet&lt;unicode_codecvt&gt;(loc);
// convert between const char* and unicode strings
unicode_codecvt::state_type state01("UNICODE", "ISO_8859-1");
initialize_state(state01);
result r1 = cvt.in(state01, e_lit, e_lit + size, efrom_next,
i_arr, i_arr + size, ito_next);
VERIFY( r1 == codecvt_base::ok );
VERIFY( !int_traits::compare(i_arr, i_lit, size) );
VERIFY( efrom_next == e_lit + size );
VERIFY( ito_next == i_arr + size );
</pre></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.codecvt.future"></a>Future</h3></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
a. things that are sketchy, or remain unimplemented:
do_encoding, max_length and length member functions
are only weakly implemented. I have no idea how to do
this correctly, and in a generic manner. Nathan?
</p></li><li><p>
b. conversions involving std::string
</p><div class="itemizedlist"><ul type="circle"><li><p>
how should operators != and == work for string of
different/same encoding?
</p></li><li><p>
what is equal? A byte by byte comparison or an
encoding then byte comparison?
</p></li><li><p>
conversions between narrow, wide, and unicode strings
</p></li></ul></div></li><li><p>
c. conversions involving std::filebuf and std::ostream
</p><div class="itemizedlist"><ul type="circle"><li><p>
how to initialize the state object in a
standards-conformant manner?
</p></li><li><p>
how to synchronize the "C" and "C++"
conversion information?
</p></li><li><p>
wchar_t/char internal buffers and conversions between
internal/external buffers?
</p></li></ul></div></li></ul></div></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="facet.codecvt.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id400718"></a><p><span class="title"><i>
The GNU C Library
</i>. </span><span class="author"><span class="firstname">Roland</span> <span class="surname">McGrath</span>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2007 FSF. </span><span class="pagenums">Chapters 6 Character Set Handling and 7 Locales and Internationalization. </span></p></div><div class="biblioentry"><a id="id487971"></a><p><span class="title"><i>
Correspondence
</i>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2002 . </span></p></div><div class="biblioentry"><a id="id452178"></a><p><span class="title"><i>
ISO/IEC 14882:1998 Programming languages - C++
</i>. </span><span class="copyright">Copyright © 1998 ISO. </span></p></div><div class="biblioentry"><a id="id452196"></a><p><span class="title"><i>
ISO/IEC 9899:1999 Programming languages - C
</i>. </span><span class="copyright">Copyright © 1999 ISO. </span></p></div><div class="biblioentry"><a id="id461282"></a><p><span class="title"><i>
System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x)
</i>. </span><span class="copyright">Copyright © 1999
The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. </span><span class="biblioid">
<a class="ulink" href="http://www.opennc.org/austin/docreg.html" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id461308"></a><p><span class="title"><i>
The C++ Programming Language, Special Edition
</i>. </span><span class="author"><span class="firstname">Bjarne</span> <span class="surname">Stroustrup</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley, Inc.. </span><span class="pagenums">Appendix D. </span><span class="publisher"><span class="publishername">
Addison Wesley
. </span></span></p></div><div class="biblioentry"><a id="id494830"></a><p><span class="title"><i>
Standard C++ IOStreams and Locales
</i>. </span><span class="subtitle">
Advanced Programmer's Guide and Reference
. </span><span class="author"><span class="firstname">Angelika</span> <span class="surname">Langer</span>. </span><span class="author"><span class="firstname">Klaus</span> <span class="surname">Kreft</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley Longman, Inc.. </span><span class="publisher"><span class="publishername">
Addison Wesley Longman
. </span></span></p></div><div class="biblioentry"><a id="id417572"></a><p><span class="title"><i>
A brief description of Normative Addendum 1
</i>. </span><span class="author"><span class="firstname">Clive</span> <span class="surname">Feather</span>. </span><span class="pagenums">Extended Character Sets. </span><span class="biblioid">
<a class="ulink" href="http://www.lysator.liu.se/c/na1.html" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id417604"></a><p><span class="title"><i>
The Unicode HOWTO
</i>. </span><span class="author"><span class="firstname">Bruno</span> <span class="surname">Haible</span>. </span><span class="biblioid">
<a class="ulink" href="ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html" target="_top">
</a>
. </span></p></div><div class="biblioentry"><a id="id427552"></a><p><span class="title"><i>
UTF-8 and Unicode FAQ for Unix/Linux
</i>. </span><span class="author"><span class="firstname">Markus</span> <span class="surname">Khun</span>. </span><span class="biblioid">
<a class="ulink" href="http://www.cl.cam.ac.uk/~mgk25/unicode.html" target="_top">
</a>
. </span></p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt06ch15.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt06ch15.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="messages.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 15. Facets aka Categories </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> messages</td></tr></table></div></body></html>

88
libstdc++-v3/doc/html/manual/concurrency.html Normal file
View File

@ -0,0 +1,88 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 40. Concurrency</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII. Extensions" /><link rel="prev" href="bk01pt12ch39.html" title="Chapter 39. Demangling" /><link rel="next" href="bk01pt12ch40s02.html" title="Implementation" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 40. Concurrency</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch39.html">Prev</a> </td><th width="60%" align="center">Part XII. Extensions</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch40s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.concurrency"></a>Chapter 40. Concurrency</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="concurrency.html#manual.ext.concurrency.design">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="concurrency.html#manual.ext.concurrency.design.threads">Interface to Locks and Mutexes</a></span></dt><dt><span class="sect2"><a href="concurrency.html#manual.ext.concurrency.design.atomics">Interface to Atomic Functions</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch40s02.html">Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch40s02.html#manual.ext.concurrency.impl.atomic_fallbacks">Using Builitin Atomic Functions</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch40s02.html#manual.ext.concurrency.impl.thread">Thread Abstraction</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch40s03.html">Use</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.concurrency.design"></a>Design</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.concurrency.design.threads"></a>Interface to Locks and Mutexes</h3></div></div></div><p>The file &lt;ext/concurrence.h&gt; contains all the higher-level
constructs for playing with threads. In contrast to the atomics layer,
the concurrence layer consists largely of types. All types are defined within <code class="code">namespace __gnu_cxx</code>.
</p><p>
These types can be used in a portable manner, regardless of the
specific environment. They are carefully designed to provide optimum
efficiency and speed, abstracting out underlying thread calls and
accesses when compiling for single-threaded situations (even on hosts
that support multiple threads.)
</p><p>The enumerated type <code class="code">_Lock_policy</code> details the set of
available locking
policies: <code class="code">_S_single</code>, <code class="code">_S_mutex</code>,
and <code class="code">_S_atomic</code>.
</p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">_S_single</code></p><p>Indicates single-threaded code that does not need locking.
</p></li><li><p><code class="code">_S_mutex</code></p><p>Indicates multi-threaded code using thread-layer abstractions.
</p></li><li><p><code class="code">_S_atomic</code></p><p>Indicates multi-threaded code using atomic operations.
</p></li></ul></div><p>The compile-time constant <code class="code">__default_lock_policy</code> is set
to one of the three values above, depending on characteristics of the
host environment and the current compilation flags.
</p><p>Two more datatypes make up the rest of the
interface: <code class="code">__mutex</code>, and <code class="code">__scoped_lock</code>.
</p><p>
</p><p>The scoped lock idiom is well-discussed within the C++
community. This version takes a <code class="code">__mutex</code> reference, and
locks it during construction of <code class="code">__scoped_locke</code> and
unlocks it during destruction. This is an efficient way of locking
critical sections, while retaining exception-safety.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.concurrency.design.atomics"></a>Interface to Atomic Functions</h3></div></div></div><p>
Two functions and one type form the base of atomic support.
</p><p>The type <code class="code">_Atomic_word</code> is a signed integral type
supporting atomic operations.
</p><p>
The two functions functions are:
</p><pre class="programlisting">
_Atomic_word
__exchange_and_add_dispatch(volatile _Atomic_word*, int);
void
__atomic_add_dispatch(volatile _Atomic_word*, int);
</pre><p>Both of these functions are declared in the header file
&lt;ext/atomicity.h&gt;, and are in <code class="code">namespace __gnu_cxx</code>.
</p><div class="itemizedlist"><ul type="disc"><li><p>
<code class="code">
__exchange_and_add_dispatch
</code>
</p><p>Adds the second argument's value to the first argument. Returns the old value.
</p></li><li><p>
<code class="code">
__atomic_add_dispatch
</code>
</p><p>Adds the second argument's value to the first argument. Has no return value.
</p></li></ul></div><p>
These functions forward to one of several specialized helper
functions, depending on the circumstances. For instance,
</p><p>
<code class="code">
__exchange_and_add_dispatch
</code>
</p><p>
Calls through to either of:
</p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">__exchange_and_add</code>
</p><p>Multi-thread version. Inlined if compiler-generated builtin atomics
can be used, otherwise resolved at link time to a non-builtin code
sequence.
</p></li><li><p><code class="code">__exchange_and_add_single</code>
</p><p>Single threaded version. Inlined.</p></li></ul></div><p>However, only <code class="code">__exchange_and_add_dispatch</code>
and <code class="code">__atomic_add_dispatch</code> should be used. These functions
can be used in a portable manner, regardless of the specific
environment. They are carefully designed to provide optimum efficiency
and speed, abstracting out atomic accesses when they are not required
(even on hosts that support compiler intrinsics for atomic
operations.)
</p><p>
In addition, there are two macros
</p><p>
<code class="code">
_GLIBCXX_READ_MEM_BARRIER
</code>
</p><p>
<code class="code">
_GLIBCXX_WRITE_MEM_BARRIER
</code>
</p><p>
Which expand to the appropriate write and read barrier required by the
host hardware and operating system.
</p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch39.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch40s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 39. Demangling </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Implementation</td></tr></table></div></body></html>

Some files were not shown because too many files have changed in this diff Show More