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