| 1 |
20 |
jlechner |
<?xml version="1.0" encoding="ISO-8859-1"?>
|
| 2 |
|
|
<!DOCTYPE html
|
| 3 |
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
| 4 |
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
| 5 |
|
|
|
| 6 |
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
| 7 |
|
|
<head>
|
| 8 |
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
|
| 9 |
|
|
<meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++, libg++, STL" />
|
| 10 |
|
|
<meta name="DESCRIPTION" content="FAQ for the GNU libstdc++ effort." />
|
| 11 |
|
|
<title>libstdc++-v3 FAQ</title>
|
| 12 |
|
|
<link rel="StyleSheet" href="../lib3styles.css" />
|
| 13 |
|
|
<link rel="Start" rev="Help" href="../documentation.html" type="text/html"
|
| 14 |
|
|
title="GNU C++ Standard Library" />
|
| 15 |
|
|
<link rel="Copyright" href="../17_intro/license.html" type="text/html" />
|
| 16 |
|
|
</head>
|
| 17 |
|
|
<body>
|
| 18 |
|
|
|
| 19 |
|
|
<h1 class="centered">libstdc++ Frequently Asked Questions</h1>
|
| 20 |
|
|
|
| 21 |
|
|
<p class="fineprint"><em>
|
| 22 |
|
|
The latest version of this document is always available at
|
| 23 |
|
|
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/faq/">
|
| 24 |
|
|
http://gcc.gnu.org/onlinedocs/libstdc++/faq/</a>. The main documentation
|
| 25 |
|
|
page is at
|
| 26 |
|
|
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html">
|
| 27 |
|
|
http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html</a>.
|
| 28 |
|
|
</em></p>
|
| 29 |
|
|
|
| 30 |
|
|
<p><em>
|
| 31 |
|
|
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
|
| 32 |
|
|
</em></p>
|
| 33 |
|
|
|
| 34 |
|
|
<!-- ####################################################### -->
|
| 35 |
|
|
<hr />
|
| 36 |
|
|
<h1>Questions</h1>
|
| 37 |
|
|
<ol>
|
| 38 |
|
|
<li><a href="#1_0">General Information</a>
|
| 39 |
|
|
<!-- I suspect these will mostly be links to/into existing documents. -->
|
| 40 |
|
|
<ol>
|
| 41 |
|
|
<li><a href="#1_1">What is libstdc++-v3?</a> </li>
|
| 42 |
|
|
<li><a href="#1_2">Why should I use libstdc++?</a> </li>
|
| 43 |
|
|
<li><a href="#1_3">Who's in charge of it?</a> </li>
|
| 44 |
|
|
<li><a href="#1_4">How do I get libstdc++?</a> </li>
|
| 45 |
|
|
<li><a href="#1_5">When is libstdc++ going to be finished?</a> </li>
|
| 46 |
|
|
<li><a href="#1_6">How do I contribute to the effort?</a> </li>
|
| 47 |
|
|
<li><a href="#1_7">What happened to libg++? I need that!</a> </li>
|
| 48 |
|
|
<li><a href="#1_8">What if I have more questions?</a> </li>
|
| 49 |
|
|
<li><a href="#1_9">What are the license terms for libstdc++-v3?</a> </li>
|
| 50 |
|
|
</ol>
|
| 51 |
|
|
</li>
|
| 52 |
|
|
|
| 53 |
|
|
<li><a href="#2_0">Installation</a>
|
| 54 |
|
|
<ol>
|
| 55 |
|
|
<li><a href="#2_1">How do I install libstdc++-v3?</a> </li>
|
| 56 |
|
|
<li><a href="#2_2">[removed]</a> </li>
|
| 57 |
|
|
<li><a href="#2_3">What is this CVS thing that you keep
|
| 58 |
|
|
mentioning?</a> </li>
|
| 59 |
|
|
<li><a href="#2_4">How do I know if it works?</a> </li>
|
| 60 |
|
|
<li><a href="#2_5">This library is HUGE! And what's libsupc++?</a> </li>
|
| 61 |
|
|
<li><a href="#2_6">Why do I get an error saying
|
| 62 |
|
|
<code>libstdc++.so.X</code> is missing when I
|
| 63 |
|
|
run my program?</a> </li>
|
| 64 |
|
|
</ol>
|
| 65 |
|
|
</li>
|
| 66 |
|
|
|
| 67 |
|
|
<li><a href="#3_0">Platform-Specific Issues</a>
|
| 68 |
|
|
<ol>
|
| 69 |
|
|
<li><a href="#3_1">Can libstdc++-v3 be used with <my
|
| 70 |
|
|
favorite compiler>?</a> </li>
|
| 71 |
|
|
<li><a href="#3_2">[removed]</a> </li>
|
| 72 |
|
|
<li><a href="#3_3">[removed]</a> </li>
|
| 73 |
|
|
<li><a href="#3_4">I can't use 'long long' on Solaris</a> </li>
|
| 74 |
|
|
<li><a href="#3_5"><code>_XOPEN_SOURCE</code> /
|
| 75 |
|
|
<code>_GNU_SOURCE</code> / etc is always defined</a>
|
| 76 |
|
|
</li>
|
| 77 |
|
|
<li><a href="#3_6">OS X ctype.h is broken! How can I hack it?</a></li>
|
| 78 |
|
|
<li><a href="#3_7">Threading is broken on i386</a></li>
|
| 79 |
|
|
<li><a href="#3_8">Recent GNU/Linux glibc required?</a></li>
|
| 80 |
|
|
<li><a href="#3_9">Can't use wchar_t/wstring on FreeBSD</a></li>
|
| 81 |
|
|
<li><a href="#3_10">MIPS atomic operations</a></li>
|
| 82 |
|
|
</ol>
|
| 83 |
|
|
</li>
|
| 84 |
|
|
|
| 85 |
|
|
<li><a href="#4_0">Known Bugs and Non-Bugs</a>
|
| 86 |
|
|
<ol>
|
| 87 |
|
|
<li><a href="#4_1">What works already?</a> </li>
|
| 88 |
|
|
<li><a href="#4_2">Bugs in gcc/g++ (not libstdc++-v3)</a> </li>
|
| 89 |
|
|
<li><a href="#4_3">Bugs in the C++ language/lib specification</a> </li>
|
| 90 |
|
|
<li><a href="#4_4">Things in libstdc++ that only look like bugs</a><ul>
|
| 91 |
|
|
<li><a href="#4_4_iostreamclear">reopening a stream fails</a> </li>
|
| 92 |
|
|
<li><a href="#4_4_Weff">-Weffc++ complains too much</a> </li>
|
| 93 |
|
|
<li><a href="#4_4_rel_ops">"ambiguous overloads"
|
| 94 |
|
|
after including an old-style header</a> </li>
|
| 95 |
|
|
<li><a href="#4_4_interface">The g++-3 headers are
|
| 96 |
|
|
<strong>not ours</strong></a> </li>
|
| 97 |
|
|
<li><a href="#4_4_glibc">compilation errors from streambuf.h</a> </li>
|
| 98 |
|
|
<li><a href="#4_4_checks">errors about <em>*Concept</em> and
|
| 99 |
|
|
<em>constraints</em> in the STL...</a> </li>
|
| 100 |
|
|
<li><a href="#4_4_dlsym">program crashes when using library code
|
| 101 |
|
|
in a dynamically-loaded library</a> </li>
|
| 102 |
|
|
<li><a href="#4_4_leak">"memory leaks" in containers</a> </li>
|
| 103 |
|
|
</ul>
|
| 104 |
|
|
</li>
|
| 105 |
|
|
<li><a href="#4_5">Aw, that's easy to fix!</a> </li>
|
| 106 |
|
|
</ol>
|
| 107 |
|
|
</li>
|
| 108 |
|
|
|
| 109 |
|
|
<li><a href="#5_0">Miscellaneous</a>
|
| 110 |
|
|
<ol>
|
| 111 |
|
|
<li><a href="#5_1">string::iterator is not char*;
|
| 112 |
|
|
vector<T>::iterator is not T*</a> </li>
|
| 113 |
|
|
<li><a href="#5_2">What's next after libstdc++-v3?</a> </li>
|
| 114 |
|
|
<li><a href="#5_3">What about the STL from SGI?</a> </li>
|
| 115 |
|
|
<li><a href="#5_4">Extensions and Backward Compatibility</a> </li>
|
| 116 |
|
|
<li><a href="#5_5">Does libstdc++ support TR1?</a> </li>
|
| 117 |
|
|
<li><a href="#5_6">Is libstdc++-v3 thread-safe?</a> </li>
|
| 118 |
|
|
<li><a href="#5_7">How do I get a copy of the ISO C++ Standard?</a> </li>
|
| 119 |
|
|
<li><a href="#5_8">What's an ABI and why is it so messy?</a> </li>
|
| 120 |
|
|
<li><a href="#5_9">How do I make std::vector<T>::capacity()
|
| 121 |
|
|
== std::vector<T>::size?</a> </li>
|
| 122 |
|
|
</ol>
|
| 123 |
|
|
</li>
|
| 124 |
|
|
|
| 125 |
|
|
</ol>
|
| 126 |
|
|
|
| 127 |
|
|
<hr />
|
| 128 |
|
|
|
| 129 |
|
|
<!-- ####################################################### -->
|
| 130 |
|
|
|
| 131 |
|
|
<h1><a name="1_0">1.0 General Information</a></h1>
|
| 132 |
|
|
<!-- I suspect these will mostly be links to/into existing documents. -->
|
| 133 |
|
|
<h2><a name="1_1">1.1 What is libstdc++-v3?</a></h2>
|
| 134 |
|
|
<p>The GNU Standard C++ Library v3 is an
|
| 135 |
|
|
ongoing project to implement the ISO 14882 Standard C++ library
|
| 136 |
|
|
as described in chapters 17 through 27 and annex D.
|
| 137 |
|
|
For those who want to see exactly how
|
| 138 |
|
|
far the project has come, or just want the latest
|
| 139 |
|
|
bleeding-edge code, the up-to-date source is available over
|
| 140 |
|
|
anonymous CVS, and can even be browsed over the Web (see
|
| 141 |
|
|
<a href="#1_4">1.4</a> below).
|
| 142 |
|
|
</p>
|
| 143 |
|
|
<p>The older libstdc++-v2 project is no longer maintained; the code
|
| 144 |
|
|
has been completely replaced and rewritten.
|
| 145 |
|
|
<a href="#4_4_interface">If you are using V2</a>, then you need to
|
| 146 |
|
|
report bugs to your system vendor, not to the V3 list.
|
| 147 |
|
|
</p>
|
| 148 |
|
|
<p>A more formal description of the V3 goals can be found in the
|
| 149 |
|
|
official <a href="../17_intro/DESIGN">design document</a>.
|
| 150 |
|
|
</p>
|
| 151 |
|
|
|
| 152 |
|
|
<hr />
|
| 153 |
|
|
<h2><a name="1_2">1.2 Why should I use libstdc++?</a></h2>
|
| 154 |
|
|
<p>The completion of the ISO C++ standardization gave the
|
| 155 |
|
|
C++ community a powerful set of reuseable tools in the form
|
| 156 |
|
|
of the C++ Standard Library. However, all existing C++
|
| 157 |
|
|
implementations are (as the Draft Standard used to say)
|
| 158 |
|
|
"incomplet and incorrekt," and many suffer from
|
| 159 |
|
|
limitations of the compilers that use them.
|
| 160 |
|
|
</p>
|
| 161 |
|
|
<p>The GNU C/C++/FORTRAN/<pick-a-language> compiler
|
| 162 |
|
|
(<code>gcc</code>, <code>g++</code>, etc) is widely considered to be
|
| 163 |
|
|
one of the leading compilers in the world. Its development
|
| 164 |
|
|
is overseen by the
|
| 165 |
|
|
<a href="http://gcc.gnu.org/">GCC team</a>. All of
|
| 166 |
|
|
the rapid development and near-legendary
|
| 167 |
|
|
<a href="http://gcc.gnu.org/gcc-3.3/buildstat.html">portability</a>
|
| 168 |
|
|
that are the hallmarks of an open-source project are being
|
| 169 |
|
|
applied to libstdc++.
|
| 170 |
|
|
</p>
|
| 171 |
|
|
<p>That means that all of the Standard classes and functions
|
| 172 |
|
|
(such as <code>string</code>, <code>vector<></code>, iostreams,
|
| 173 |
|
|
and algorithms) will be freely available and fully compliant.
|
| 174 |
|
|
Programmers will no longer need to "roll their own"
|
| 175 |
|
|
nor be worried about platform-specific incompatibilities.
|
| 176 |
|
|
</p>
|
| 177 |
|
|
|
| 178 |
|
|
<hr />
|
| 179 |
|
|
<h2><a name="1_3">1.3 Who's in charge of it?</a></h2>
|
| 180 |
|
|
<p>The libstdc++ project is contributed to by several developers
|
| 181 |
|
|
all over the world, in the same way as GCC or Linux.
|
| 182 |
|
|
Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, Ulrich Drepper,
|
| 183 |
|
|
Loren James Rittle, and Paolo Carlini are the lead maintainers of
|
| 184 |
|
|
the CVS archive.
|
| 185 |
|
|
</p>
|
| 186 |
|
|
<p>Development and discussion is held on the libstdc++ mailing
|
| 187 |
|
|
list. Subscribing to the list, or searching the list
|
| 188 |
|
|
archives, is open to everyone. You can read instructions for
|
| 189 |
|
|
doing so on the <a href="http://gcc.gnu.org/libstdc++/">homepage</a>.
|
| 190 |
|
|
If you have questions, ideas, code, or are just curious, sign up!
|
| 191 |
|
|
</p>
|
| 192 |
|
|
|
| 193 |
|
|
<hr />
|
| 194 |
|
|
<h2><a name="1_4">1.4 How do I get libstdc++?</a></h2>
|
| 195 |
|
|
<p>The <a href="http://gcc.gnu.org/libstdc++/">homepage</a>
|
| 196 |
|
|
has instructions for retrieving the latest CVS sources, and for
|
| 197 |
|
|
browsing the CVS sources over the web.
|
| 198 |
|
|
</p>
|
| 199 |
|
|
<p>Stable versions of libstdc++-v3 are included with releases of
|
| 200 |
|
|
<a href="http://gcc.gnu.org/releases.html">the GCC compilers</a>.
|
| 201 |
|
|
</p>
|
| 202 |
|
|
<p>The subset commonly known as the Standard Template Library
|
| 203 |
|
|
(chapters 23 through 25, mostly) is adapted from the final release
|
| 204 |
|
|
of the SGI STL, with extensive changes.
|
| 205 |
|
|
</p>
|
| 206 |
|
|
|
| 207 |
|
|
<hr />
|
| 208 |
|
|
<h2><a name="1_5">1.5 When is libstdc++ going to be finished?</a></h2>
|
| 209 |
|
|
<!-- <p>Nathan Myers gave the best of all possible answers in <a
|
| 210 |
|
|
href="http://www.deja.com/getdoc.xp?AN=469581698&fmt=text">a
|
| 211 |
|
|
Usenet article</a>.</p>
|
| 212 |
|
|
which is no longer available, thanks deja...-->
|
| 213 |
|
|
<p>Nathan Myers gave the best of all possible answers, responding to a
|
| 214 |
|
|
Usenet article asking this question: <em>Sooner, if you help.</em>
|
| 215 |
|
|
</p>
|
| 216 |
|
|
|
| 217 |
|
|
<hr />
|
| 218 |
|
|
<h2><a name="1_6">1.6 How do I contribute to the effort?</a></h2>
|
| 219 |
|
|
<p>Here is <a href="../17_intro/contribute.html">a
|
| 220 |
|
|
page devoted to this topic</a>. Subscribing to the mailing
|
| 221 |
|
|
list (see above, or the homepage) is a very good idea if you
|
| 222 |
|
|
have something to contribute, or if you have spare time and
|
| 223 |
|
|
want to help. Contributions don't have to be in the form of
|
| 224 |
|
|
source code; anybody who is willing to help write
|
| 225 |
|
|
documentation, for example, or has found a bug in code that
|
| 226 |
|
|
we all thought was working, is more than welcome!
|
| 227 |
|
|
</p>
|
| 228 |
|
|
|
| 229 |
|
|
<hr />
|
| 230 |
|
|
<h2><a name="1_7">1.7 What happened to libg++? I need that!</a></h2>
|
| 231 |
|
|
<p>The most recent libg++ README states that libg++ is no longer
|
| 232 |
|
|
being actively maintained. It should not be used for new
|
| 233 |
|
|
projects, and is only being kicked along to support older code.
|
| 234 |
|
|
</p>
|
| 235 |
|
|
<p>The libg++ was designed and created when there was no Standard
|
| 236 |
|
|
to provide guidance. Classes like linked lists are now provided
|
| 237 |
|
|
for by <code>list<T></code> and do not need to be created by
|
| 238 |
|
|
<code>genclass</code>. (For that matter, templates exist now and
|
| 239 |
|
|
are well-supported, whereas genclass (mostly) predates them.)
|
| 240 |
|
|
</p>
|
| 241 |
|
|
<p>There are other classes in libg++ that are not specified in the
|
| 242 |
|
|
ISO Standard (e.g., statistical analysis). While there are a
|
| 243 |
|
|
lot of really useful things that are used by a lot of people
|
| 244 |
|
|
(e.g., statistics :-), the Standards Committee couldn't include
|
| 245 |
|
|
everything, and so a lot of those "obvious" classes
|
| 246 |
|
|
didn't get included.
|
| 247 |
|
|
</p>
|
| 248 |
|
|
<p>Since libstdc++ is an implementation of the Standard Library, we
|
| 249 |
|
|
have no plans at this time to include non-Standard utilities
|
| 250 |
|
|
in the implementation, however handy they are. (The extensions
|
| 251 |
|
|
provided in the SGI STL aren't maintained by us and don't get
|
| 252 |
|
|
a lot of our attention, because they don't require a lot of our
|
| 253 |
|
|
time.) It is entirely plausable that the "useful stuff"
|
| 254 |
|
|
from libg++ might be extracted into an updated utilities library,
|
| 255 |
|
|
but nobody has started such a project yet.
|
| 256 |
|
|
</p>
|
| 257 |
|
|
<p>(The <a href="http://www.boost.org/">Boost</a> site houses free
|
| 258 |
|
|
C++ libraries that do varying things, and happened to be started
|
| 259 |
|
|
by members of the Standards Committee. Certain "useful
|
| 260 |
|
|
stuff" classes will probably migrate there.)
|
| 261 |
|
|
</p>
|
| 262 |
|
|
<p>For the bold and/or desperate, the
|
| 263 |
|
|
<a href="http://gcc.gnu.org/extensions.html">GCC extensions page</a>
|
| 264 |
|
|
describes where to find the last libg++ source.
|
| 265 |
|
|
</p>
|
| 266 |
|
|
|
| 267 |
|
|
<hr />
|
| 268 |
|
|
<h2><a name="1_8">1.8 What if I have more questions?</a></h2>
|
| 269 |
|
|
<p>If you have read the README and RELEASE-NOTES files, and your
|
| 270 |
|
|
question remains unanswered, then just ask the mailing list.
|
| 271 |
|
|
At present, you do not need to be subscribed to the list to
|
| 272 |
|
|
send a message to it. More information is available on the
|
| 273 |
|
|
homepage (including how to browse the list archives); to send
|
| 274 |
|
|
to the list, use <a href="mailto:libstdc++@gcc.gnu.org">
|
| 275 |
|
|
<code>libstdc++@gcc.gnu.org</code></a>.
|
| 276 |
|
|
</p>
|
| 277 |
|
|
<p>If you have a question that you think should be included here,
|
| 278 |
|
|
or if you have a question <em>about</em> a question/answer here,
|
| 279 |
|
|
contact <a href="mailto:pme@gcc.gnu.org">Phil Edwards</a>
|
| 280 |
|
|
or <a href="mailto:gdr@gcc.gnu.org">Gabriel Dos Reis</a>.
|
| 281 |
|
|
</p>
|
| 282 |
|
|
|
| 283 |
|
|
<hr />
|
| 284 |
|
|
<h2><a name="1_9">1.9 What are the license terms for libstdc++-v3?</a></h2>
|
| 285 |
|
|
<p>See <a href="../17_intro/license.html">our license description</a>
|
| 286 |
|
|
for these and related questions.
|
| 287 |
|
|
</p>
|
| 288 |
|
|
|
| 289 |
|
|
<hr />
|
| 290 |
|
|
<h1><a name="2_0">2.0 Installation</a></h1>
|
| 291 |
|
|
<h2><a name="2_1">2.1 How do I install libstdc++-v3?</a></h2>
|
| 292 |
|
|
<p>Complete instructions are not given here (this is a FAQ, not
|
| 293 |
|
|
an installation document), but the tools required are few:
|
| 294 |
|
|
</p>
|
| 295 |
|
|
<ul>
|
| 296 |
|
|
<li> A 3.x release of GCC. Note that building GCC is much
|
| 297 |
|
|
easier and more automated than building the GCC 2.[78]
|
| 298 |
|
|
series was. If you are using GCC 2.95, you can still
|
| 299 |
|
|
build earlier snapshots of libstdc++.
|
| 300 |
|
|
</li>
|
| 301 |
|
|
<li> GNU Make is required for GCC 3.4 and later.
|
| 302 |
|
|
</li>
|
| 303 |
|
|
<li> The GNU Autotools are needed if you are messing with
|
| 304 |
|
|
the configury or makefiles.
|
| 305 |
|
|
</li>
|
| 306 |
|
|
</ul>
|
| 307 |
|
|
<p>The file <a href="../documentation.html">documentation.html</a>
|
| 308 |
|
|
provides a good overview of the steps necessary to build, install,
|
| 309 |
|
|
and use the library. Instructions for configuring the library
|
| 310 |
|
|
with new flags such as --enable-threads are there also, as well as
|
| 311 |
|
|
patches and instructions for working with GCC 2.95.
|
| 312 |
|
|
</p>
|
| 313 |
|
|
<p>The top-level install.html and
|
| 314 |
|
|
<a href="../17_intro/RELEASE-NOTES">RELEASE-NOTES</a> files contain
|
| 315 |
|
|
the exact build and installation instructions. You may wish to
|
| 316 |
|
|
browse those files over CVSweb ahead of time to get a feel for
|
| 317 |
|
|
what's required. RELEASE-NOTES is located in the
|
| 318 |
|
|
".../docs/17_intro/" directory of the distribution.
|
| 319 |
|
|
</p>
|
| 320 |
|
|
|
| 321 |
|
|
<hr />
|
| 322 |
|
|
<h2><a name="2_2">2.2 [removed]</a></h2>
|
| 323 |
|
|
<p>This question has become moot and has been removed. The stub
|
| 324 |
|
|
is here to preserve numbering (and hence links/bookmarks).
|
| 325 |
|
|
</p>
|
| 326 |
|
|
|
| 327 |
|
|
<hr />
|
| 328 |
|
|
<h2><a name="2_3">2.3 What is this CVS thing that you
|
| 329 |
|
|
keep mentioning?</a></h2>
|
| 330 |
|
|
<p>The <em>Concurrent Versions System</em> is one of several revision
|
| 331 |
|
|
control packages. It was selected for GNU projects because it's
|
| 332 |
|
|
free (speech), free (beer), and very high quality. The <a
|
| 333 |
|
|
href="http://www.gnu.org/software/cvs/cvs.html">CVS entry in
|
| 334 |
|
|
the GNU software catalogue</a> has a better description as
|
| 335 |
|
|
well as a
|
| 336 |
|
|
<a href="http://www.cvshome.org/">link to the makers of CVS</a>.
|
| 337 |
|
|
</p>
|
| 338 |
|
|
<p>The "anonymous client checkout" feature of CVS is
|
| 339 |
|
|
similar to anonymous FTP in that it allows anyone to retrieve
|
| 340 |
|
|
the latest libstdc++ sources.
|
| 341 |
|
|
</p>
|
| 342 |
|
|
<p>After the first of April, American users will have a
|
| 343 |
|
|
"/pharmacy" command-line option...
|
| 344 |
|
|
<!-- wonder how long that'll live -->
|
| 345 |
|
|
</p>
|
| 346 |
|
|
|
| 347 |
|
|
<hr />
|
| 348 |
|
|
<h2><a name="2_4">2.4 How do I know if it works?</a></h2>
|
| 349 |
|
|
<p>libstdc++-v3 comes with its own testsuite. You do not need
|
| 350 |
|
|
to actually install the library ("<code>make
|
| 351 |
|
|
install</code>") to run the testsuite, but you do need
|
| 352 |
|
|
DejaGNU, as described
|
| 353 |
|
|
<a href="http://gcc.gnu.org/install/test.html">here</a>.
|
| 354 |
|
|
</p>
|
| 355 |
|
|
<p>To run the testsuite on the library after building it, use
|
| 356 |
|
|
"make check" while in your build directory. To run
|
| 357 |
|
|
the testsuite on the library after building and installing it,
|
| 358 |
|
|
use "make check-install" instead.
|
| 359 |
|
|
</p>
|
| 360 |
|
|
<p>If you find bugs in the testsuite programs themselves, or if you
|
| 361 |
|
|
think of a new test program that should be added to the suite,
|
| 362 |
|
|
<strong>please</strong> write up your idea and send it to the list!
|
| 363 |
|
|
</p>
|
| 364 |
|
|
|
| 365 |
|
|
<hr />
|
| 366 |
|
|
<h2><a name="2_5">2.5 This library is HUGE! And what's libsupc++?</a></h2>
|
| 367 |
|
|
<p>Usually the size of libraries on disk isn't noticeable. When a
|
| 368 |
|
|
link editor (or simply "linker") pulls things from a
|
| 369 |
|
|
static archive library, only the necessary object files are copied
|
| 370 |
|
|
into your executable, not the entire library. Unfortunately, even
|
| 371 |
|
|
if you only need a single function or variable from an object file,
|
| 372 |
|
|
the entire object file is extracted. (There's nothing unique to C++
|
| 373 |
|
|
or libstdc++-v3 about this; it's just common behavior, given here
|
| 374 |
|
|
for background reasons.)
|
| 375 |
|
|
</p>
|
| 376 |
|
|
<p>Some of the object files which make up libstdc++.a are rather large.
|
| 377 |
|
|
If you create a statically-linked executable with
|
| 378 |
|
|
<code> -static</code>, those large object files are suddenly part
|
| 379 |
|
|
of your executable. Historically the best way around this was to
|
| 380 |
|
|
only place a very few functions (often only a single one) in each
|
| 381 |
|
|
source/object file; then extracting a single function is the same
|
| 382 |
|
|
as extracting a single .o file. For libstdc++-v3 this is only
|
| 383 |
|
|
possible to a certain extent; the object files in question contain
|
| 384 |
|
|
template classes and template functions, pre-instantiated, and
|
| 385 |
|
|
splitting those up causes severe maintenance headaches.
|
| 386 |
|
|
</p>
|
| 387 |
|
|
<p>It's not a bug, and it's not really a problem. Nevertheless, some
|
| 388 |
|
|
people don't like it, so here are two pseudo-solutions:
|
| 389 |
|
|
</p>
|
| 390 |
|
|
<p>If the only functions from libstdc++.a which you need are
|
| 391 |
|
|
language support functions (those listed in <a
|
| 392 |
|
|
href="../18_support/howto.html">clause 18</a> of the
|
| 393 |
|
|
standard, e.g., <code>new</code> and <code>delete</code>),
|
| 394 |
|
|
then try linking against <code>libsupc++.a</code> (Using
|
| 395 |
|
|
<code>gcc</code> instead of <code>g++</code> and explicitly
|
| 396 |
|
|
linking in <code>-lsupc++</code> for the final link step will
|
| 397 |
|
|
do it). This library contains only those support routines,
|
| 398 |
|
|
one per object file. But if you are using anything from the
|
| 399 |
|
|
rest of the library, such as IOStreams or vectors, then
|
| 400 |
|
|
you'll still need pieces from <code>libstdc++.a</code>.
|
| 401 |
|
|
</p>
|
| 402 |
|
|
<p>The second method is one we hope to incorporate into the library
|
| 403 |
|
|
build process. Some platforms can place each function and variable
|
| 404 |
|
|
into its own section in a .o file. The GNU linker can then perform
|
| 405 |
|
|
garbage collection on unused sections; this reduces the situation
|
| 406 |
|
|
to only copying needed functions into the executable, as before,
|
| 407 |
|
|
but all happens automatically.
|
| 408 |
|
|
</p>
|
| 409 |
|
|
<p>Unfortunately the garbage collection in GNU ld is buggy; sections
|
| 410 |
|
|
(corresponding to functions and variables) which <em>are</em> used
|
| 411 |
|
|
are mistakenly removed, leading to horrible crashes when your
|
| 412 |
|
|
executable starts up. For the time being, this feature is not used
|
| 413 |
|
|
when building the library.
|
| 414 |
|
|
</p>
|
| 415 |
|
|
|
| 416 |
|
|
<hr />
|
| 417 |
|
|
<h2><a name="2_6">2.6 Why do I get an error saying
|
| 418 |
|
|
<code>libstdc++.so.X</code> is missing when I run
|
| 419 |
|
|
my program?</a></h2>
|
| 420 |
|
|
<p>Depending on your platform and library version, the message might
|
| 421 |
|
|
be similar to one of the following:
|
| 422 |
|
|
</p>
|
| 423 |
|
|
<pre>
|
| 424 |
|
|
./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
|
| 425 |
|
|
|
| 426 |
|
|
/usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found </pre>
|
| 427 |
|
|
|
| 428 |
|
|
<p>This doesn't mean that the shared library isn't installed, only
|
| 429 |
|
|
that the dynamic linker can't find it. When a dynamically-linked
|
| 430 |
|
|
executable is run the linker finds and loads the required shared
|
| 431 |
|
|
libraries by searching a pre-configured list of directories. If
|
| 432 |
|
|
the directory where you've installed libstdc++ is not in this
|
| 433 |
|
|
list then the libraries won't be found. The simplest way to fix
|
| 434 |
|
|
this is to use the <code>LD_LIBRARY_PATH</code> environment
|
| 435 |
|
|
variable, which is a colon-separated list of directories in which
|
| 436 |
|
|
the linker will search for shared libraries:
|
| 437 |
|
|
</p>
|
| 438 |
|
|
<pre>
|
| 439 |
|
|
LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH
|
| 440 |
|
|
export LD_LIBRARY_PATH </pre>
|
| 441 |
|
|
<p>The exact environment variable to use will depend on your platform,
|
| 442 |
|
|
e.g. DYLD_LIBRARY_PATH for Darwin,
|
| 443 |
|
|
LD_LIBRARY_PATH_32/LD_LIBRARY_PATH_64 for Solaris 32-/64-bit,
|
| 444 |
|
|
LD_LIBRARYN32_PATH/LD_LIBRARY64_PATH for Irix N32/64-bit ABIs
|
| 445 |
|
|
and SHLIB_PATH for HP-UX.
|
| 446 |
|
|
</p>
|
| 447 |
|
|
<p>See the man pages for <code>ld(1)</code>, <code>ldd(1)</code> and
|
| 448 |
|
|
<code>ldconfig(8)</code> for more information. The dynamic linker
|
| 449 |
|
|
has different names on different platforms but the man page is
|
| 450 |
|
|
usually called something such as <code>ld.so / rtld / dld.so</code>.
|
| 451 |
|
|
</p>
|
| 452 |
|
|
|
| 453 |
|
|
<hr />
|
| 454 |
|
|
<h1><a name="3_0">3.0 Platform-Specific Issues</a></h1>
|
| 455 |
|
|
<h2><a name="3_1">3.1 Can libstdc++-v3 be used with <my
|
| 456 |
|
|
favorite compiler>?</a></h2>
|
| 457 |
|
|
<p>Probably not. Yet.</p>
|
| 458 |
|
|
<p>Because GCC advances so rapidly, development and testing of
|
| 459 |
|
|
libstdc++ is being done almost entirely under that compiler.
|
| 460 |
|
|
If you are curious about whether other, lesser compilers
|
| 461 |
|
|
(*grin*) support libstdc++, you are more than welcome to try.
|
| 462 |
|
|
Configuring and building the library (see above) will still
|
| 463 |
|
|
require certain tools, however. Also keep in mind that
|
| 464 |
|
|
<em>building</em> libstdc++ does not imply that your compiler
|
| 465 |
|
|
will be able to <em>use</em> all of the features found in the
|
| 466 |
|
|
C++ Standard Library.
|
| 467 |
|
|
</p>
|
| 468 |
|
|
<p>Since the goal of ISO Standardization is for all C++
|
| 469 |
|
|
implementations to be able to share code, the final libstdc++
|
| 470 |
|
|
should, in theory, be usable under any ISO-compliant
|
| 471 |
|
|
compiler. It will still be targeted and optimized for
|
| 472 |
|
|
GCC/g++, however.
|
| 473 |
|
|
</p>
|
| 474 |
|
|
|
| 475 |
|
|
<hr />
|
| 476 |
|
|
<h2><a name="3_2">3.2 [removed]</a></h2>
|
| 477 |
|
|
<p>This question has become moot and has been removed. The stub
|
| 478 |
|
|
is here to preserve numbering (and hence links/bookmarks).
|
| 479 |
|
|
</p>
|
| 480 |
|
|
|
| 481 |
|
|
<hr />
|
| 482 |
|
|
<h2><a name="3_3">3.3 [removed]</a></h2>
|
| 483 |
|
|
<p>This question has become moot and has been removed. The stub
|
| 484 |
|
|
is here to preserve numbering (and hence links/bookmarks).
|
| 485 |
|
|
</p>
|
| 486 |
|
|
|
| 487 |
|
|
<hr />
|
| 488 |
|
|
<h2><a name="3_4">3.4 I can't use 'long long' on Solaris</a></h2>
|
| 489 |
|
|
<p>By default we try to support the C99 <code>long long</code> type.
|
| 490 |
|
|
This requires that certain functions from your C library be present.
|
| 491 |
|
|
</p>
|
| 492 |
|
|
<p>Up through release 3.0.2 the tests performed were too general, and
|
| 493 |
|
|
this feature was disabled when it did not need to be. The most
|
| 494 |
|
|
commonly reported platform affected was Solaris.
|
| 495 |
|
|
</p>
|
| 496 |
|
|
<p>This has been fixed for 3.0.3 and onwards.
|
| 497 |
|
|
</p>
|
| 498 |
|
|
|
| 499 |
|
|
<hr />
|
| 500 |
|
|
<h2><a name="3_5">3.5 <code>_XOPEN_SOURCE</code> / <code>_GNU_SOURCE</code>
|
| 501 |
|
|
/ etc is always defined</a></h2>
|
| 502 |
|
|
<p>On Solaris, g++ (but not gcc) always defines the preprocessor
|
| 503 |
|
|
macro <code>_XOPEN_SOURCE</code>. On GNU/Linux, the same happens
|
| 504 |
|
|
with <code>_GNU_SOURCE</code>. (This is not an exhaustive list;
|
| 505 |
|
|
other macros and other platforms are also affected.)
|
| 506 |
|
|
</p>
|
| 507 |
|
|
<p>These macros are typically used in C library headers, guarding new
|
| 508 |
|
|
versions of functions from their older versions. The C++ standard
|
| 509 |
|
|
library includes the C standard library, but it requires the C90
|
| 510 |
|
|
version, which for backwards-compatability reasons is often not the
|
| 511 |
|
|
default for many vendors.
|
| 512 |
|
|
</p>
|
| 513 |
|
|
<p>More to the point, the C++ standard requires behavior which is only
|
| 514 |
|
|
available on certain platforms after certain symbols are defined.
|
| 515 |
|
|
Usually the issue involves I/O-related typedefs. In order to
|
| 516 |
|
|
ensure correctness, the compiler simply predefines those symbols.
|
| 517 |
|
|
</p>
|
| 518 |
|
|
<p>Note that it's not enough to #define them only when the library is
|
| 519 |
|
|
being built (during installation). Since we don't have an 'export'
|
| 520 |
|
|
keyword, much of the library exists as headers, which means that
|
| 521 |
|
|
the symbols must also be defined as your programs are parsed and
|
| 522 |
|
|
compiled.
|
| 523 |
|
|
</p>
|
| 524 |
|
|
<p>To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in
|
| 525 |
|
|
the gcc config headers for your target (and try changing them to
|
| 526 |
|
|
see what happens when building complicated code). You can also run
|
| 527 |
|
|
<code>"g++ -E -dM - < /dev/null"</code> to display
|
| 528 |
|
|
a list of predefined macros for any particular installation.
|
| 529 |
|
|
</p>
|
| 530 |
|
|
<p>This has been discussed on the mailing lists
|
| 531 |
|
|
<a href="http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris">quite a bit</a>.
|
| 532 |
|
|
</p>
|
| 533 |
|
|
<p>This method is something of a wart. We'd like to find a cleaner
|
| 534 |
|
|
solution, but nobody yet has contributed the time.
|
| 535 |
|
|
</p>
|
| 536 |
|
|
|
| 537 |
|
|
<hr />
|
| 538 |
|
|
<h2><a name="3_6">3.6 OS X ctype.h is broken! How can I hack it?</a></h2>
|
| 539 |
|
|
<p>This is a long-standing bug in the OS X support. Fortunately,
|
| 540 |
|
|
the patch is quite simple, and well-known.
|
| 541 |
|
|
<a href="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html"> Here's a
|
| 542 |
|
|
link to the solution.</a>
|
| 543 |
|
|
</p>
|
| 544 |
|
|
|
| 545 |
|
|
<hr />
|
| 546 |
|
|
<h2><a name="3_7">3.7 Threading is broken on i386</a></h2>
|
| 547 |
|
|
<p>Support for atomic integer operations is/was broken on i386
|
| 548 |
|
|
platforms. The assembly code accidentally used opcodes that are
|
| 549 |
|
|
only available on the i486 and later. So if you configured GCC
|
| 550 |
|
|
to target, for example, i386-linux, but actually used the programs
|
| 551 |
|
|
on an i686, then you would encounter no problems. Only when
|
| 552 |
|
|
actually running the code on a i386 will the problem appear.
|
| 553 |
|
|
</p>
|
| 554 |
|
|
<p>This is fixed in 3.2.2.
|
| 555 |
|
|
</p>
|
| 556 |
|
|
|
| 557 |
|
|
<hr />
|
| 558 |
|
|
<h2><a name="3_8">3.8 Recent GNU/Linux glibc required?</a></h2>
|
| 559 |
|
|
<p>When running on GNU/Linux, libstdc++ 3.2.1 (shared library version
|
| 560 |
|
|
5.0.1) and later uses localization and formatting code from the system
|
| 561 |
|
|
C library (glibc) version 2.2.5. That version of glibc is over a
|
| 562 |
|
|
year old and contains necessary bugfixes. Many GNU/Linux distros make
|
| 563 |
|
|
glibc version 2.3.x available now.
|
| 564 |
|
|
</p>
|
| 565 |
|
|
<p>The guideline is simple: the more recent the C++ library, the
|
| 566 |
|
|
more recent the C library. (This is also documented in the main
|
| 567 |
|
|
GCC installation instructions.)
|
| 568 |
|
|
</p>
|
| 569 |
|
|
|
| 570 |
|
|
<hr />
|
| 571 |
|
|
<h2><a name="3_9">3.9 Can't use wchar_t/wstring on FreeBSD</a></h2>
|
| 572 |
|
|
<p>At the moment there are a few problems in FreeBSD's support for
|
| 573 |
|
|
wide character functions, and as a result the libstdc++ configury
|
| 574 |
|
|
decides that wchar_t support should be disabled. Once the underlying
|
| 575 |
|
|
problems are fixed in FreeBSD (soon), the library support will
|
| 576 |
|
|
automatically enable itself.
|
| 577 |
|
|
</p>
|
| 578 |
|
|
<p>You can fix the problems yourself, and learn more about the situation,
|
| 579 |
|
|
by reading
|
| 580 |
|
|
<a href="http://gcc.gnu.org/ml/libstdc++/2003-02/subjects.html#00286">
|
| 581 |
|
|
this short thread</a> ("_GLIBCPP_USE_WCHAR_T undefined in
|
| 582 |
|
|
FreeBSD's c++config.h?").
|
| 583 |
|
|
</p>
|
| 584 |
|
|
|
| 585 |
|
|
<hr />
|
| 586 |
|
|
<h2><a name="3_10">3.10 MIPS atomic operations</a></h2>
|
| 587 |
|
|
<p>The atomic locking routines for MIPS targets requires MIPS II
|
| 588 |
|
|
and later. A patch went in just after the 3.3 release to
|
| 589 |
|
|
make mips* use the generic implementation instead. You can also
|
| 590 |
|
|
configure for mipsel-elf as a workaround.
|
| 591 |
|
|
</p>
|
| 592 |
|
|
<p>mips*-*-linux* continues to use the MIPS II routines, and more
|
| 593 |
|
|
work in this area is expected.
|
| 594 |
|
|
</p>
|
| 595 |
|
|
|
| 596 |
|
|
<hr />
|
| 597 |
|
|
<h1><a name="4_0">4.0 Known Bugs and Non-Bugs</a></h1>
|
| 598 |
|
|
<em>Note that this section can get rapdily outdated -- such is the
|
| 599 |
|
|
nature of an open-source project. For the latest information, join
|
| 600 |
|
|
the mailing list or look through recent archives. The RELEASE-
|
| 601 |
|
|
NOTES and BUGS files are generally kept up-to-date.</em>
|
| 602 |
|
|
|
| 603 |
|
|
<p>For 3.0.1, the most common "bug" is an apparently missing
|
| 604 |
|
|
"<code>../</code>" in include/Makefile, resulting in files
|
| 605 |
|
|
like gthr.h and gthr-single.h not being found. Please read
|
| 606 |
|
|
<a href="http://gcc.gnu.org/install/configure.html">the configuration
|
| 607 |
|
|
instructions for GCC</a>,
|
| 608 |
|
|
specifically the part about configuring in a separate build directory,
|
| 609 |
|
|
and how strongly recommended it is. Building in the source directory
|
| 610 |
|
|
is fragile, is rarely tested, and tends to break, as in this case.
|
| 611 |
|
|
This was fixed for 3.0.2.
|
| 612 |
|
|
</p>
|
| 613 |
|
|
|
| 614 |
|
|
<p>For 3.1, the most common "bug" is a parse error when using
|
| 615 |
|
|
<code><fstream></code>, ending with a message,
|
| 616 |
|
|
"<code>bits/basic_file.h:52: parse error before `{'
|
| 617 |
|
|
token</code>." Please read
|
| 618 |
|
|
<a href="http://gcc.gnu.org/install/">the installation instructions for
|
| 619 |
|
|
GCC</a>, specifically the part about not installing newer versions on
|
| 620 |
|
|
top of older versions. If you install 3.1 over a 3.0.x release, then
|
| 621 |
|
|
the wrong basic_file.h header will be found (its location changed
|
| 622 |
|
|
between releases).
|
| 623 |
|
|
</p>
|
| 624 |
|
|
|
| 625 |
|
|
<p><strong>Please do not report these as bugs. We know about them.</strong>
|
| 626 |
|
|
Reporting this -- or any other problem that's already been fixed --
|
| 627 |
|
|
hinders the development of GCC, because we have to take time to
|
| 628 |
|
|
respond to your report. Thank you.
|
| 629 |
|
|
</p>
|
| 630 |
|
|
|
| 631 |
|
|
<hr />
|
| 632 |
|
|
<h2><a name="4_1">4.1 What works already?</a></h2>
|
| 633 |
|
|
<p>Short answer: Pretty much everything <em>works</em> except for some
|
| 634 |
|
|
corner cases. Also, localization is incomplete. For whether it works
|
| 635 |
|
|
well, or as you expect it to work, see 5.2.
|
| 636 |
|
|
</p>
|
| 637 |
|
|
<p>Long answer: See the docs/html/17_intro/CHECKLIST file, which is
|
| 638 |
|
|
badly outdated... Also see the RELEASE-NOTES file, which is kept
|
| 639 |
|
|
more up to date.
|
| 640 |
|
|
</p>
|
| 641 |
|
|
|
| 642 |
|
|
<hr />
|
| 643 |
|
|
<h2><a name="4_2">4.2 Bugs in gcc/g++ (not libstdc++-v3)</a></h2>
|
| 644 |
|
|
<p>This is by no means meant to be complete nor exhaustive, but
|
| 645 |
|
|
mentions some problems that users may encounter when building
|
| 646 |
|
|
or using libstdc++. If you are experiencing one of these
|
| 647 |
|
|
problems, you can find more information on the libstdc++ and
|
| 648 |
|
|
the GCC mailing lists.
|
| 649 |
|
|
</p>
|
| 650 |
|
|
<p>Before reporting a bug, examine the
|
| 651 |
|
|
<a href="http://gcc.gnu.org/bugs.html">bugs database</a> with the
|
| 652 |
|
|
category set to "libstdc++". The BUGS file in the source
|
| 653 |
|
|
tree also tracks known serious problems.
|
| 654 |
|
|
</p>
|
| 655 |
|
|
<ul>
|
| 656 |
|
|
<li>Debugging is problematic, due to bugs in line-number generation
|
| 657 |
|
|
(mostly fixed in the compiler) and gdb lagging behind the
|
| 658 |
|
|
compiler (lack of personnel). We recommend configuring the
|
| 659 |
|
|
compiler using <code>--with-dwarf2</code> if the DWARF2
|
| 660 |
|
|
debugging format is not already the default on your platform.
|
| 661 |
|
|
Also,
|
| 662 |
|
|
<a href="http://gcc.gnu.org/ml/libstdc++/2002-02/msg00034.html">changing your
|
| 663 |
|
|
GDB settings</a> can have a profound effect on your C++ debugging
|
| 664 |
|
|
experiences. :-)</li>
|
| 665 |
|
|
</ul>
|
| 666 |
|
|
|
| 667 |
|
|
<hr />
|
| 668 |
|
|
<h2><a name="4_3">4.3 Bugs in the C++ language/lib specification</a></h2>
|
| 669 |
|
|
<p>Yes, unfortunately, there are some. In a
|
| 670 |
|
|
<a href="http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html">message
|
| 671 |
|
|
to the list</a>, Nathan Myers announced that he has started a list of
|
| 672 |
|
|
problems in the ISO C++ Standard itself, especially with
|
| 673 |
|
|
regard to the chapters that concern the library. The list
|
| 674 |
|
|
itself is
|
| 675 |
|
|
<a href="http://www.cantrip.org/draft-bugs.txt">posted on his
|
| 676 |
|
|
website</a>. Developers who are having problems interpreting
|
| 677 |
|
|
the Standard may wish to consult his notes.
|
| 678 |
|
|
</p>
|
| 679 |
|
|
<p>For those people who are not part of the ISO Library Group
|
| 680 |
|
|
(i.e., nearly all of us needing to read this page in the first
|
| 681 |
|
|
place :-), a public list of the library defects is occasionally
|
| 682 |
|
|
published <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/">here</a>.
|
| 683 |
|
|
Some of these have resulted in <a href="#5_2">code changes</a>.
|
| 684 |
|
|
</p>
|
| 685 |
|
|
|
| 686 |
|
|
<hr />
|
| 687 |
|
|
<h2><a name="4_4">4.4 Things in libstdc++ that only look like bugs</a></h2>
|
| 688 |
|
|
<p>There are things which are not bugs in the compiler (4.2) nor
|
| 689 |
|
|
the language specification (4.3), but aren't really bugs in
|
| 690 |
|
|
libstdc++, either. Really! Please do not report these as bugs.
|
| 691 |
|
|
</p>
|
| 692 |
|
|
<p><a name="4_4_Weff"><strong>-Weffc++</strong></a>
|
| 693 |
|
|
The biggest of these is the quadzillions of warnings about the
|
| 694 |
|
|
library headers emitted when <code>-Weffc++</code> is used. Making
|
| 695 |
|
|
libstdc++ "-Weffc++-clean" is not a goal of the project,
|
| 696 |
|
|
for a few reasons. Mainly, that option tries to enforce
|
| 697 |
|
|
object-oriented programming, while the Standard Library isn't
|
| 698 |
|
|
necessarily trying to be OO.
|
| 699 |
|
|
</p>
|
| 700 |
|
|
<p><a name="4_4_iostreamclear"><strong>reopening a stream fails</strong>
|
| 701 |
|
|
</a> Did I just say that -Weffc++ was our biggest false-bug report?
|
| 702 |
|
|
I lied. (It used to be.) Today it seems to be reports that after
|
| 703 |
|
|
executing a sequence like
|
| 704 |
|
|
</p>
|
| 705 |
|
|
<pre>
|
| 706 |
|
|
#include <fstream>
|
| 707 |
|
|
...
|
| 708 |
|
|
std::fstream fs("a_file");
|
| 709 |
|
|
// .
|
| 710 |
|
|
// . do things with fs...
|
| 711 |
|
|
// .
|
| 712 |
|
|
fs.close();
|
| 713 |
|
|
fs.open("a_new_file");</pre>
|
| 714 |
|
|
<p>all operations on the re-opened <code>fs</code> will fail, or at
|
| 715 |
|
|
least act very strangely. Yes, they often will, especially if
|
| 716 |
|
|
<code>fs</code> reached the EOF state on the previous file. The
|
| 717 |
|
|
reason is that the state flags are <strong>not</strong> cleared
|
| 718 |
|
|
on a successful call to open(). The standard unfortunately did
|
| 719 |
|
|
not specify behavior in this case, and to everybody's great sorrow,
|
| 720 |
|
|
the <a href="../ext/howto.html#5">proposed LWG resolution in
|
| 721 |
|
|
DR #22</a> is to leave the flags unchanged. You must insert a call
|
| 722 |
|
|
to <code>fs.clear()</code> between the calls to close() and open(),
|
| 723 |
|
|
and then everything will work like we all expect it to work.
|
| 724 |
|
|
<strong>Update:</strong> for GCC 4.0 we implemented the resolution
|
| 725 |
|
|
of <a href="../ext/howto.html#5">DR #409</a> and open() now calls
|
| 726 |
|
|
<code>clear()</code> on success!
|
| 727 |
|
|
</p>
|
| 728 |
|
|
<p><a name="4_4_rel_ops"><strong>rel_ops</strong></a>
|
| 729 |
|
|
Another is the <code>rel_ops</code> namespace and the template
|
| 730 |
|
|
comparison operator functions contained therein. If they become
|
| 731 |
|
|
visible in the same namespace as other comparison functions
|
| 732 |
|
|
(e.g., '<code>using</code>' them and the <iterator> header),
|
| 733 |
|
|
then you will suddenly be faced with huge numbers of ambiguity
|
| 734 |
|
|
errors. This was discussed on the -v3 list; Nathan Myers
|
| 735 |
|
|
<a href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html">sums
|
| 736 |
|
|
things up here</a>. The collisions with vector/string iterator
|
| 737 |
|
|
types have been fixed for 3.1. <!-- more links to email here -->
|
| 738 |
|
|
</p>
|
| 739 |
|
|
<h3><a name="4_4_interface">The g++-3 headers are <em>not ours</em></a></h3>
|
| 740 |
|
|
<p>If you have found an extremely broken header file which is
|
| 741 |
|
|
causing problems for you, look carefully before submitting a
|
| 742 |
|
|
"high" priority bug report (which you probably shouldn't
|
| 743 |
|
|
do anyhow; see the last paragraph of the page describing
|
| 744 |
|
|
<a href="http://gcc.gnu.org/bugs.html">the GCC bug database</a>).
|
| 745 |
|
|
</p>
|
| 746 |
|
|
<p>If the headers are in <code>${prefix}/include/g++-3</code>, or if
|
| 747 |
|
|
the installed library's name looks like <code>libstdc++-2.10.a</code>
|
| 748 |
|
|
or <code>libstdc++-libc6-2.10.so</code>, then you are using the old
|
| 749 |
|
|
libstdc++-v2 library, which is nonstandard and unmaintained. Do not
|
| 750 |
|
|
report problems with -v2 to the -v3 mailing list.
|
| 751 |
|
|
</p>
|
| 752 |
|
|
<p>For GCC versions 3.0 and 3.1 the libstdc++-v3 header files are
|
| 753 |
|
|
installed in <code>${prefix}/include/g++-v3</code> (see the 'v'?).
|
| 754 |
|
|
Starting with version 3.2 the headers are installed in
|
| 755 |
|
|
<code>${prefix}/include/c++/${version}</code> as this prevents
|
| 756 |
|
|
headers from previous versions being found by mistake.
|
| 757 |
|
|
</p>
|
| 758 |
|
|
<p><a name="4_4_glibc"><strong>glibc</strong></a>
|
| 759 |
|
|
If you're on a GNU/Linux system and have just upgraded to
|
| 760 |
|
|
glibc 2.2, but are still using gcc 2.95.2, then you should have
|
| 761 |
|
|
read the glibc FAQ, specifically 2.34:
|
| 762 |
|
|
</p>
|
| 763 |
|
|
<pre>
|
| 764 |
|
|
2.34. When compiling C++ programs, I get a compilation error in streambuf.h.
|
| 765 |
|
|
|
| 766 |
|
|
{BH} You are using g++ 2.95.2? After upgrading to glibc 2.2, you need to
|
| 767 |
|
|
apply a patch to the include files in /usr/include/g++, because the fpos_t
|
| 768 |
|
|
type has changed in glibc 2.2. The patch is at
|
| 769 |
|
|
http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
| 770 |
|
|
</pre>
|
| 771 |
|
|
<p>Note that 2.95.x shipped with the
|
| 772 |
|
|
<a href="#4_4_interface">old v2 library</a> which is no longer
|
| 773 |
|
|
maintained. Also note that gcc 2.95.3 fixes this problem, but
|
| 774 |
|
|
requires a separate patch for libstdc++-v3.
|
| 775 |
|
|
</p>
|
| 776 |
|
|
<p><a name="4_4_checks"><strong>concept checks</strong></a>
|
| 777 |
|
|
If you see compilation errors containing messages about
|
| 778 |
|
|
<code> <em>foo</em>Concept </code>and a<code> constraints </code>
|
| 779 |
|
|
member function, then most likely you have violated one of the
|
| 780 |
|
|
requirements for types used during instantiation of template
|
| 781 |
|
|
containers and functions. For example, EqualityComparableConcept
|
| 782 |
|
|
appears if your types must be comparable with == and you have not
|
| 783 |
|
|
provided this capability (a typo, or wrong visibility, or you
|
| 784 |
|
|
just plain forgot, etc).
|
| 785 |
|
|
</p>
|
| 786 |
|
|
<p>More information, including how to optionally enable/disable the
|
| 787 |
|
|
checks, is available
|
| 788 |
|
|
<a href="../19_diagnostics/howto.html#3">here</a>.
|
| 789 |
|
|
</p>
|
| 790 |
|
|
<p><a name="4_4_dlsym"><strong>dlopen/dlsym</strong></a>
|
| 791 |
|
|
If you are using the C++ library across dynamically-loaded
|
| 792 |
|
|
objects, make certain that you are passing the correct options
|
| 793 |
|
|
when compiling and linking:
|
| 794 |
|
|
</p>
|
| 795 |
|
|
<pre>
|
| 796 |
|
|
// compile your library components
|
| 797 |
|
|
g++ -fPIC -c a.cc
|
| 798 |
|
|
g++ -fPIC -c b.cc
|
| 799 |
|
|
...
|
| 800 |
|
|
g++ -fPIC -c z.cc
|
| 801 |
|
|
|
| 802 |
|
|
// create your library
|
| 803 |
|
|
g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o
|
| 804 |
|
|
|
| 805 |
|
|
// link the executable
|
| 806 |
|
|
g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl</pre>
|
| 807 |
|
|
<p><a name="4_4_leak"><strong>"memory leaks" in containers</strong></a>
|
| 808 |
|
|
A few people have reported that the standard containers appear
|
| 809 |
|
|
to leak memory when tested with memory checkers such as
|
| 810 |
|
|
<a href="http://developer.kde.org/~sewardj/">valgrind</a>.
|
| 811 |
|
|
The library's default allocators keep free memory in a pool
|
| 812 |
|
|
for later reuse, rather than returning it to the OS. Although
|
| 813 |
|
|
this memory is always reachable by the library and is never
|
| 814 |
|
|
lost, memory debugging tools can report it as a leak. If you
|
| 815 |
|
|
want to test the library for memory leaks please read
|
| 816 |
|
|
<a href="../debug.html#mem">Tips for memory leak hunting</a>
|
| 817 |
|
|
first.
|
| 818 |
|
|
</p>
|
| 819 |
|
|
|
| 820 |
|
|
<hr />
|
| 821 |
|
|
<h2><a name="4_5">4.5 Aw, that's easy to fix!</a></h2>
|
| 822 |
|
|
<p>If you have found a bug in the library and you think you have
|
| 823 |
|
|
a working fix, then send it in! The main GCC site has a page
|
| 824 |
|
|
on <a href="http://gcc.gnu.org/contribute.html">submitting
|
| 825 |
|
|
patches</a> that covers the procedure, but for libstdc++ you
|
| 826 |
|
|
should also send the patch to our mailing list in addition to
|
| 827 |
|
|
the GCC patches mailing list. The libstdc++
|
| 828 |
|
|
<a href="../17_intro/contribute.html">contributors' page</a>
|
| 829 |
|
|
also talks about how to submit patches.
|
| 830 |
|
|
</p>
|
| 831 |
|
|
<p>In addition to the description, the patch, and the ChangeLog
|
| 832 |
|
|
entry, it is a Good Thing if you can additionally create a small
|
| 833 |
|
|
test program to test for the presence of the bug that your
|
| 834 |
|
|
patch fixes. Bugs have a way of being reintroduced; if an old
|
| 835 |
|
|
bug creeps back in, it will be caught immediately by the
|
| 836 |
|
|
<a href="#2_4">testsuite</a> -- but only if such a test exists.
|
| 837 |
|
|
</p>
|
| 838 |
|
|
|
| 839 |
|
|
<hr />
|
| 840 |
|
|
<h1><a name="5_0">5.0 Miscellaneous</a></h1>
|
| 841 |
|
|
<h2><a name="5_1">5.1 string::iterator is not char*;
|
| 842 |
|
|
vector<T>::iterator is not T*</a></h2>
|
| 843 |
|
|
<p>If you have code that depends on container<T> iterators
|
| 844 |
|
|
being implemented as pointer-to-T, your code is broken.
|
| 845 |
|
|
</p>
|
| 846 |
|
|
<p>While there are arguments for iterators to be implemented in
|
| 847 |
|
|
that manner, A) they aren't very good ones in the long term,
|
| 848 |
|
|
and B) they were never guaranteed by the Standard anyway. The
|
| 849 |
|
|
type-safety achieved by making iterators a real class rather
|
| 850 |
|
|
than a typedef for <code>T*</code> outweighs nearly all opposing
|
| 851 |
|
|
arguments.
|
| 852 |
|
|
</p>
|
| 853 |
|
|
<p>Code which does assume that a vector iterator <code> i </code>
|
| 854 |
|
|
is a pointer can often be fixed by changing <code> i </code> in
|
| 855 |
|
|
certain expressions to <code> &*i </code>. Future revisions
|
| 856 |
|
|
of the Standard are expected to bless this usage for
|
| 857 |
|
|
vector<> (but not for basic_string<>).
|
| 858 |
|
|
</p>
|
| 859 |
|
|
|
| 860 |
|
|
<hr />
|
| 861 |
|
|
<h2><a name="5_2">5.2 What's next after libstdc++-v3?</a></h2>
|
| 862 |
|
|
<p>Hopefully, not much. The goal of libstdc++-v3 is to produce
|
| 863 |
|
|
a fully-compliant, fully-portable Standard Library. After that,
|
| 864 |
|
|
we're mostly done: there won't <em>be</em> any more compliance
|
| 865 |
|
|
work to do. However:
|
| 866 |
|
|
</p>
|
| 867 |
|
|
<ol>
|
| 868 |
|
|
<li><p>The ISO Committee will meet periodically to review Defect Reports
|
| 869 |
|
|
in the C++ Standard. Undoubtedly some of these will result in
|
| 870 |
|
|
changes to the Standard, which will be reflected in patches to
|
| 871 |
|
|
libstdc++. Some of that is already happening, see <a href="#4_3">4.3</a>. Some of
|
| 872 |
|
|
those changes are being predicted by the library maintainers, and
|
| 873 |
|
|
we add code to the library based on what the current proposed
|
| 874 |
|
|
resolution specifies. Those additions are listed in
|
| 875 |
|
|
<a href="../ext/howto.html#5">the extensions page</a>.
|
| 876 |
|
|
</p></li>
|
| 877 |
|
|
<li><p>Performance tuning. Lots of performance tuning. This too is
|
| 878 |
|
|
already underway for post-3.0 releases, starting with memory
|
| 879 |
|
|
expansion in container classes and buffer usage in synchronized
|
| 880 |
|
|
stream objects.
|
| 881 |
|
|
</p></li>
|
| 882 |
|
|
<li><p>An ABI for libstdc++ is being developed, so that
|
| 883 |
|
|
multiple binary-incompatible copies of the library can be replaced
|
| 884 |
|
|
with a single backwards-compatible library, like libgcc_s.so is.
|
| 885 |
|
|
</p></li>
|
| 886 |
|
|
<li><p>The current libstdc++ contains extensions to the Library which
|
| 887 |
|
|
must be explicitly requested by client code (for example, the
|
| 888 |
|
|
hash tables from SGI). Other extensions may be added to
|
| 889 |
|
|
libstdc++-v3 if they seem to be "standard" enough.
|
| 890 |
|
|
(For example, the "long long" type from C99.)
|
| 891 |
|
|
Bugfixes and rewrites (to improve or fix thread safety, for
|
| 892 |
|
|
instance) will of course be a continuing task.
|
| 893 |
|
|
</p></li>
|
| 894 |
|
|
<li><p>There is an effort underway to add significant extensions to
|
| 895 |
|
|
the standard library specification. The latest version of this effort is
|
| 896 |
|
|
described in
|
| 897 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
|
| 898 |
|
|
The C++ Library Technical Report 1</a>.
|
| 899 |
|
|
See <a href="#5_5">5.5</a>.
|
| 900 |
|
|
</p></li>
|
| 901 |
|
|
</ol>
|
| 902 |
|
|
<p><a href="http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html">This
|
| 903 |
|
|
question</a> about the next libstdc++ prompted some brief but
|
| 904 |
|
|
interesting
|
| 905 |
|
|
<a href="http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html">speculation</a>.
|
| 906 |
|
|
</p>
|
| 907 |
|
|
|
| 908 |
|
|
<hr />
|
| 909 |
|
|
<h2><a name="5_3">5.3 What about the STL from SGI?</a></h2>
|
| 910 |
|
|
<p>The <a href="http://www.sgi.com/tech/stl/">STL from SGI</a>,
|
| 911 |
|
|
version 3.3, was the final merge of the STL codebase. The
|
| 912 |
|
|
code in libstdc++ contains many fixes and changes, and
|
| 913 |
|
|
the SGI code is no longer under active
|
| 914 |
|
|
development. We expect that no future merges will take place.
|
| 915 |
|
|
</p>
|
| 916 |
|
|
<p>In particular, <code>string</code> is not from SGI and makes no
|
| 917 |
|
|
use of their "rope" class (which is included as an
|
| 918 |
|
|
optional extension), nor is <code>valarray</code> and some others.
|
| 919 |
|
|
Classes like <code>vector<></code> are, however we have
|
| 920 |
|
|
made significant changes to them since then.
|
| 921 |
|
|
</p>
|
| 922 |
|
|
<p>The FAQ for SGI's STL (one jump off of their main page) is
|
| 923 |
|
|
recommended reading.
|
| 924 |
|
|
</p>
|
| 925 |
|
|
|
| 926 |
|
|
<hr />
|
| 927 |
|
|
<h2><a name="5_4">5.4 Extensions and Backward Compatibility</a></h2>
|
| 928 |
|
|
<p>Headers in the <code>ext</code> and <code>backward</code>
|
| 929 |
|
|
subdirectories should be referred to by their relative paths:
|
| 930 |
|
|
<!-- Careful, the leading spaces in PRE show up directly. -->
|
| 931 |
|
|
</p>
|
| 932 |
|
|
<pre>
|
| 933 |
|
|
#include <ext/hash_map> </pre>
|
| 934 |
|
|
<p>rather than using <code>-I</code> or other options. This is more
|
| 935 |
|
|
portable and forward-compatible. (The situation is the same as
|
| 936 |
|
|
that of other headers whose directories are not searched directly,
|
| 937 |
|
|
e.g., <code><sys/stat.h></code>, <code><X11/Xlib.h></code>.
|
| 938 |
|
|
</p>
|
| 939 |
|
|
|
| 940 |
|
|
<p>At this time most of the features of the SGI STL extension have been
|
| 941 |
|
|
replaced by standardized libraries.
|
| 942 |
|
|
In particular, the unordered_map and unordered_set containers of TR1
|
| 943 |
|
|
are suitable replacement for the non-standard hash_map and hash_set
|
| 944 |
|
|
containers in the SGI STL. See <a href="#5_5">5.5</a> for more details.
|
| 945 |
|
|
</p>
|
| 946 |
|
|
|
| 947 |
|
|
<p>The extensions are no longer in the global or <code>std</code>
|
| 948 |
|
|
namespaces, instead they are declared in the <code>__gnu_cxx</code>
|
| 949 |
|
|
namespace. For maximum portability, consider defining a namespace
|
| 950 |
|
|
alias to use to talk about extensions, e.g.:
|
| 951 |
|
|
</p>
|
| 952 |
|
|
<pre>
|
| 953 |
|
|
#ifdef __GNUC__
|
| 954 |
|
|
#if __GNUC__ < 3
|
| 955 |
|
|
#include <hash_map.h>
|
| 956 |
|
|
namespace Sgi { using ::hash_map; }; // inherit globals
|
| 957 |
|
|
#else
|
| 958 |
|
|
#include <ext/hash_map>
|
| 959 |
|
|
#if __GNUC_MINOR__ == 0
|
| 960 |
|
|
namespace Sgi = std; // GCC 3.0
|
| 961 |
|
|
#else
|
| 962 |
|
|
namespace Sgi = ::__gnu_cxx; // GCC 3.1 and later
|
| 963 |
|
|
#endif
|
| 964 |
|
|
#endif
|
| 965 |
|
|
#else // ... there are other compilers, right?
|
| 966 |
|
|
namespace Sgi = std;
|
| 967 |
|
|
#endif
|
| 968 |
|
|
|
| 969 |
|
|
Sgi::hash_map<int,int> my_map; </pre>
|
| 970 |
|
|
<p>This is a bit cleaner than defining typedefs for all the
|
| 971 |
|
|
instantiations you might need.
|
| 972 |
|
|
</p>
|
| 973 |
|
|
<p><strong>Note:</strong> explicit template specializations must
|
| 974 |
|
|
be declared in the same namespace as the original template.
|
| 975 |
|
|
This means you cannot use a namespace alias when declaring
|
| 976 |
|
|
an explicit specialization.
|
| 977 |
|
|
</p>
|
| 978 |
|
|
<p>Extensions to the library have
|
| 979 |
|
|
<a href="../ext/howto.html">their own page</a>.
|
| 980 |
|
|
</p>
|
| 981 |
|
|
|
| 982 |
|
|
<hr />
|
| 983 |
|
|
<h2><a name="5_5">5.5 Does libstdc++ support TR1?</a></h2>
|
| 984 |
|
|
|
| 985 |
|
|
<p>The C++ Standard Library Technical Report adds many new features to
|
| 986 |
|
|
the library. The latest version of this effort is described in
|
| 987 |
|
|
<a href=
|
| 988 |
|
|
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
|
| 989 |
|
|
Technical Report 1</a>.
|
| 990 |
|
|
</p>
|
| 991 |
|
|
|
| 992 |
|
|
<p>libstdc++ strives to implement all of TR1.
|
| 993 |
|
|
An <a href="../ext/tr1.html">overview</a> of the implementation status
|
| 994 |
|
|
is available.
|
| 995 |
|
|
</p>
|
| 996 |
|
|
|
| 997 |
|
|
<p>Briefly, the features of TR1 and the current status are:
|
| 998 |
|
|
</p>
|
| 999 |
|
|
|
| 1000 |
|
|
<p><strong>Reference_wrapper - Complete -</strong>
|
| 1001 |
|
|
Useful to pass references to functions that take their parameters
|
| 1002 |
|
|
by value.
|
| 1003 |
|
|
</p>
|
| 1004 |
|
|
|
| 1005 |
|
|
<p><strong>Reference-counted smart pointers - Complete -</strong>
|
| 1006 |
|
|
The shared_ptr and weak_ptr allow several object to know about a
|
| 1007 |
|
|
pointer and whether it is valid. When the last reference to the
|
| 1008 |
|
|
pointer is destroyed the pointer is freed.
|
| 1009 |
|
|
</p>
|
| 1010 |
|
|
|
| 1011 |
|
|
<p><strong>Function objects - Complete -</strong>
|
| 1012 |
|
|
Function return types (i.e, result_of), the functions template
|
| 1013 |
|
|
mem_fn (a generalization of mem_fun and mem_fun_red), function
|
| 1014 |
|
|
object binders (e.g, bind, a generalization of bind1st and bind2nd),
|
| 1015 |
|
|
and polymorhpic function wrappers (e.g, class template function).
|
| 1016 |
|
|
</p>
|
| 1017 |
|
|
|
| 1018 |
|
|
<p><strong>Type traits - Complete -</strong>
|
| 1019 |
|
|
The type_traits class gives templates the ability to probe
|
| 1020 |
|
|
information about the input type and enable type-dependent logic
|
| 1021 |
|
|
to be performed without the need of template specializations.
|
| 1022 |
|
|
</p>
|
| 1023 |
|
|
|
| 1024 |
|
|
<p><strong>Fixed-size arrays - Complete -</strong>
|
| 1025 |
|
|
The array class implements small fixed-sized arrays with container
|
| 1026 |
|
|
semantics.
|
| 1027 |
|
|
</p>
|
| 1028 |
|
|
|
| 1029 |
|
|
<p><strong>Unordered containers - Complete -</strong>
|
| 1030 |
|
|
The unordered_set, unordered_map, unordered_multiset, and
|
| 1031 |
|
|
unordered_multimap containers are hashed versions of the map, set,
|
| 1032 |
|
|
multimap, and multiset containers respectively. These classes are
|
| 1033 |
|
|
suitable replacements for the SGI STL hash_map and hash_set
|
| 1034 |
|
|
extensions.
|
| 1035 |
|
|
</p>
|
| 1036 |
|
|
|
| 1037 |
|
|
<p><strong>Tuples - Complete -</strong>
|
| 1038 |
|
|
The tuple class implements small heterogeneous arrays. This is an
|
| 1039 |
|
|
enhanced pair. In fact, the standard pair is enhanced with a tuple
|
| 1040 |
|
|
interface.
|
| 1041 |
|
|
</p>
|
| 1042 |
|
|
|
| 1043 |
|
|
<p><strong>C99 compatibility - Under construction - </strong>
|
| 1044 |
|
|
There are many features designed to minimize the divergence of the C
|
| 1045 |
|
|
and the C++ languages.
|
| 1046 |
|
|
</p>
|
| 1047 |
|
|
|
| 1048 |
|
|
<p><strong>Special functions - Under construction - </strong>
|
| 1049 |
|
|
Twenty-three mathematical functions familiar to physicists and
|
| 1050 |
|
|
engineers are included: cylindrical and spherical Bessel and Neumann
|
| 1051 |
|
|
functions, hypergeometric functions, Laguerre polynomials, Legendre
|
| 1052 |
|
|
functions, elliptic integrals, exponential integrals and the Riemann
|
| 1053 |
|
|
zeta function all for your computing pleasure.
|
| 1054 |
|
|
</p>
|
| 1055 |
|
|
|
| 1056 |
|
|
<p><strong>A regular expression engine</strong>
|
| 1057 |
|
|
This library provides for regular expression objects with traversal
|
| 1058 |
|
|
of text with return of subexpressions.
|
| 1059 |
|
|
</p>
|
| 1060 |
|
|
|
| 1061 |
|
|
<p><strong>A random number engine</strong>
|
| 1062 |
|
|
This library contains randow number generators with several different
|
| 1063 |
|
|
choices of distribution.
|
| 1064 |
|
|
</p>
|
| 1065 |
|
|
|
| 1066 |
|
|
<hr />
|
| 1067 |
|
|
<h2><a name="5_6">5.6 Is libstdc++-v3 thread-safe?</a></h2>
|
| 1068 |
|
|
<p>libstdc++-v3 strives to be thread-safe when all of the following
|
| 1069 |
|
|
conditions are met:
|
| 1070 |
|
|
</p>
|
| 1071 |
|
|
<ul>
|
| 1072 |
|
|
<li>The system's libc is itself thread-safe,</li>
|
| 1073 |
|
|
<li><code>gcc -v</code> reports a thread model other than 'single',</li>
|
| 1074 |
|
|
<li>[pre-3.3 only] a non-generic implementation of atomicity.h
|
| 1075 |
|
|
exists for the architecture in question.</li>
|
| 1076 |
|
|
</ul>
|
| 1077 |
|
|
<p>The user-code must guard against concurrent method calls which may
|
| 1078 |
|
|
access any particular library object's state. Typically, the
|
| 1079 |
|
|
application programmer may infer what object locks must be held
|
| 1080 |
|
|
based on the objects referenced in a method call. Without getting
|
| 1081 |
|
|
into great detail, here is an example which requires user-level
|
| 1082 |
|
|
locks:
|
| 1083 |
|
|
</p>
|
| 1084 |
|
|
<pre>
|
| 1085 |
|
|
library_class_a shared_object_a;
|
| 1086 |
|
|
|
| 1087 |
|
|
thread_main () {
|
| 1088 |
|
|
library_class_b *object_b = new library_class_b;
|
| 1089 |
|
|
shared_object_a.add_b (object_b); // must hold lock for shared_object_a
|
| 1090 |
|
|
shared_object_a.mutate (); // must hold lock for shared_object_a
|
| 1091 |
|
|
}
|
| 1092 |
|
|
|
| 1093 |
|
|
// Multiple copies of thread_main() are started in independent threads.</pre>
|
| 1094 |
|
|
<p>Under the assumption that object_a and object_b are never exposed to
|
| 1095 |
|
|
another thread, here is an example that should not require any
|
| 1096 |
|
|
user-level locks:
|
| 1097 |
|
|
</p>
|
| 1098 |
|
|
<pre>
|
| 1099 |
|
|
thread_main () {
|
| 1100 |
|
|
library_class_a object_a;
|
| 1101 |
|
|
library_class_b *object_b = new library_class_b;
|
| 1102 |
|
|
object_a.add_b (object_b);
|
| 1103 |
|
|
object_a.mutate ();
|
| 1104 |
|
|
} </pre>
|
| 1105 |
|
|
<p>All library objects are safe to use in a multithreaded program as
|
| 1106 |
|
|
long as each thread carefully locks out access by any other
|
| 1107 |
|
|
thread while it uses any object visible to another thread, i.e.,
|
| 1108 |
|
|
treat library objects like any other shared resource. In general,
|
| 1109 |
|
|
this requirement includes both read and write access to objects;
|
| 1110 |
|
|
unless otherwise documented as safe, do not assume that two threads
|
| 1111 |
|
|
may access a shared standard library object at the same time.
|
| 1112 |
|
|
</p>
|
| 1113 |
|
|
<p>See chapters <a href="../17_intro/howto.html#3">17</a> (library
|
| 1114 |
|
|
introduction), <a href="../23_containers/howto.html#3">23</a>
|
| 1115 |
|
|
(containers), and <a href="../27_io/howto.html#9">27</a> (I/O) for
|
| 1116 |
|
|
more information.
|
| 1117 |
|
|
</p>
|
| 1118 |
|
|
|
| 1119 |
|
|
<hr />
|
| 1120 |
|
|
<h2><a name="5_7">5.7 How do I get a copy of the ISO C++ Standard?</a></h2>
|
| 1121 |
|
|
<p>Copies of the full ISO 14882 standard are available on line via the
|
| 1122 |
|
|
ISO mirror site for committee members. Non-members, or those who
|
| 1123 |
|
|
have not paid for the privilege of sitting on the committee and
|
| 1124 |
|
|
sustained their two-meeting commitment for voting rights, may get a
|
| 1125 |
|
|
copy of the standard from their respective national standards
|
| 1126 |
|
|
organization. In the USA, this national standards organization is
|
| 1127 |
|
|
ANSI and their website is right <a href="http://www.ansi.org">here</a>.
|
| 1128 |
|
|
(And if you've already registered with them, clicking this link will
|
| 1129 |
|
|
take you to directly to the place where you can
|
| 1130 |
|
|
<a href="http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%3A2003">buy
|
| 1131 |
|
|
the standard on-line</a>.
|
| 1132 |
|
|
</p>
|
| 1133 |
|
|
<p>Who is your country's member body? Visit the
|
| 1134 |
|
|
<a href="http://www.iso.ch/">ISO homepage</a> and find out!
|
| 1135 |
|
|
</p>
|
| 1136 |
|
|
|
| 1137 |
|
|
<hr />
|
| 1138 |
|
|
<h2><a name="5_8">5.8 What's an ABI and why is it so messy?</a></h2>
|
| 1139 |
|
|
<p>"ABI" stands for "Application Binary Interface."
|
| 1140 |
|
|
Conventionally, it refers to a great mass of details about how
|
| 1141 |
|
|
arguments are arranged on the call stack and/or in registers, and
|
| 1142 |
|
|
how various types are arranged and padded in structs. A single CPU
|
| 1143 |
|
|
design may suffer multiple ABIs designed by different development
|
| 1144 |
|
|
tool vendors who made different choices, or even by the same vendor
|
| 1145 |
|
|
for different target applications or compiler versions. In ideal
|
| 1146 |
|
|
circumstances the CPU designer presents one ABI and all the OSes and
|
| 1147 |
|
|
compilers use it. In practice every ABI omits details that compiler
|
| 1148 |
|
|
implementers (consciously or accidentally) must choose for themselves.
|
| 1149 |
|
|
</p>
|
| 1150 |
|
|
<p>That ABI definition suffices for compilers to generate code so a
|
| 1151 |
|
|
program can interact safely with an OS and its lowest-level libraries.
|
| 1152 |
|
|
Users usually want an ABI to encompass more detail, allowing libraries
|
| 1153 |
|
|
built with different compilers (or different releases of the same
|
| 1154 |
|
|
compiler!) to be linked together. For C++, this includes many more
|
| 1155 |
|
|
details than for C, and CPU designers (for good reasons elaborated
|
| 1156 |
|
|
below) have not stepped up to publish C++ ABIs. The details include
|
| 1157 |
|
|
virtual function implementation, struct inheritance layout, name
|
| 1158 |
|
|
mangling, and exception handling. Such an ABI has been defined for
|
| 1159 |
|
|
GNU C++, and is immediately useful for embedded work relying only on
|
| 1160 |
|
|
a "free-standing implementation" that doesn't include (much
|
| 1161 |
|
|
of) the standard library. It is a good basis for the work to come.
|
| 1162 |
|
|
</p>
|
| 1163 |
|
|
<p>A useful C++ ABI must also incorporate many details of the standard
|
| 1164 |
|
|
library implementation. For a C ABI, the layouts of a few structs
|
| 1165 |
|
|
(such as FILE, stat, jmpbuf, and the like) and a few macros suffice.
|
| 1166 |
|
|
For C++, the details include the complete set of names of functions
|
| 1167 |
|
|
and types used, the offsets of class members and virtual functions,
|
| 1168 |
|
|
and the actual definitions of all inlines. C++ exposes many more
|
| 1169 |
|
|
library details to the caller than C does. It makes defining
|
| 1170 |
|
|
a complete ABI a much bigger undertaking, and requires not just
|
| 1171 |
|
|
documenting library implementation details, but carefully designing
|
| 1172 |
|
|
those details so that future bug fixes and optimizations don't
|
| 1173 |
|
|
force breaking the ABI.
|
| 1174 |
|
|
</p>
|
| 1175 |
|
|
<p>There are ways to help isolate library implementation details from the
|
| 1176 |
|
|
ABI, but they trade off against speed. Library details used in
|
| 1177 |
|
|
inner loops (e.g., getchar) must be exposed and frozen for all
|
| 1178 |
|
|
time, but many others may reasonably be kept hidden from user code,
|
| 1179 |
|
|
so they may later be changed. Deciding which, and implementing
|
| 1180 |
|
|
the decisions, must happen before you can reasonably document a
|
| 1181 |
|
|
candidate C++ ABI that encompasses the standard library.
|
| 1182 |
|
|
</p>
|
| 1183 |
|
|
|
| 1184 |
|
|
<hr />
|
| 1185 |
|
|
<h2><a name="5_9">5.9 How do I make std::vector<T>::capacity()
|
| 1186 |
|
|
== std::vector<T>::size()?</a> </h2>
|
| 1187 |
|
|
<!-- referenced by 21_strings/howto.html#6 -->
|
| 1188 |
|
|
<p>The standard idiom for deallocating a <code>std::vector<T></code>'s
|
| 1189 |
|
|
unused memory is to create a temporary copy of the vector and swap their
|
| 1190 |
|
|
contents, e.g. for <code>std::vector<T> v</code>
|
| 1191 |
|
|
</p>
|
| 1192 |
|
|
<pre>
|
| 1193 |
|
|
std::vector<T>(v).swap(v);
|
| 1194 |
|
|
</pre>
|
| 1195 |
|
|
<p>The copy will take O(n) time and the swap is constant time.
|
| 1196 |
|
|
</p>
|
| 1197 |
|
|
<p>See <a href='../21_strings/howto.html#6'>Shrink-to-fit strings</a> for
|
| 1198 |
|
|
a similar solution for strings.
|
| 1199 |
|
|
</p>
|
| 1200 |
|
|
|
| 1201 |
|
|
<!-- ####################################################### -->
|
| 1202 |
|
|
|
| 1203 |
|
|
<hr />
|
| 1204 |
|
|
<p class="fineprint"><em>
|
| 1205 |
|
|
See <a href="../17_intro/license.html">license.html</a> for copying conditions.
|
| 1206 |
|
|
Comments and suggestions are welcome, and may be sent to
|
| 1207 |
|
|
<a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing list</a>.
|
| 1208 |
|
|
</em></p>
|
| 1209 |
|
|
|
| 1210 |
|
|
|
| 1211 |
|
|
</body>
|
| 1212 |
|
|
</html>
|
| 1213 |
|
|
|
