1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="Notes for the libstdc++ extensions." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Extensions</title>
<link rel="StyleSheet" href="../lib3styles.css" />
</head>
<body>
<h1 class="centered"><a name="top">Extensions</a></h1>
<p>Here we will make an attempt at describing the non-Standard extensions to
the library. Some of these are from SGI's STL, some of these are GNU's,
and some just seemed to appear on the doorstep.
</p>
<p><strong>Before you leap in and use these</strong>, be aware of two things:
</p>
<ol>
<li>Non-Standard means exactly that. The behavior, and the very
existence, of these extensions may change with little or no
warning. (Ideally, the really good ones will appear in the next
revision of C++.) Also, other platforms, other compilers, other
versions of g++ or libstdc++-v3 may not recognize these names, or
treat them differently, or... </li>
<li>You should know how to <a href="../faq/index.html#5_4">access
these headers properly</a>. </li>
</ol>
<!-- ####################################################### -->
<hr />
<h1>Contents</h1>
<ul>
<li><a href="#1">Ropes and trees and hashes, oh my!</a></li>
<li><a href="#2">Added members and types</a></li>
<li><a href="#3">Allocators (versions 3.0, 3.1, 3.2)</a></li>
<li><a href="#6">Allocators (version 3.3)</a></li>
<li><a href="#4">Compile-time checks</a></li>
<li><a href="#5">LWG Issues</a></li>
</ul>
<hr />
<!-- ####################################################### -->
<h2><a name="1">Ropes and trees and hashes, oh my!</a></h2>
<p>The SGI headers</p>
<pre>
<bvector>
<hash_map>
<hash_set>
<rope>
<slist>
<tree>
</pre>
<p>are all here; <code><bvector></code> exposes the old bit_vector
class that was used before specialization of vector<bool> was
available (it's actually a typedef for the specialization now).
<code><hash_map></code> and <code><hash_set></code>
are discussed further below. <code><rope></code> is the SGI
specialization for large strings ("rope," "large
strings," get it? love those SGI folks).
<code><slist></code> is a singly-linked list, for when the
doubly-linked <code>list<></code> is too much space overhead, and
<code><tree></code> exposes the red-black tree classes used in the
implementation of the standard maps and sets.
</p>
<p>Okay, about those hashing classes... I'm going to foist most of the
work off onto SGI's own site.
</p>
<p>Each of the associative containers map, multimap, set, and multiset
have a counterpart which uses a
<a href="http://www.sgi.com/Technology/STL/HashFunction.html">hashing
function</a> to do the arranging, instead of a strict weak ordering
function. The classes take as one of their template parameters a
function object that will return the hash value; by default, an
instantiation of
<a href="http://www.sgi.com/Technology/STL/hash.html">hash</a>.
You should specialize this functor for your class, or define your own,
before trying to use one of the hashing classes.
</p>
<p>The hashing classes support all the usual associative container
functions, as well as some extra constructors specifying the number
of buckets, etc.
</p>
<p>Why would you want to use a hashing class instead of the
"normal" implementations? Matt Austern writes:
</p>
<blockquote><em>[W]ith a well chosen hash function, hash tables
generally provide much better average-case performance than binary
search trees, and much worse worst-case performance. So if your
implementation has hash_map, if you don't mind using nonstandard
components, and if you aren't scared about the possibility of
pathological cases, you'll probably get better performance from
hash_map.</em></blockquote>
<p>(Side note: for those of you wondering, <strong>"Why wasn't a hash
table included in the Standard in the first #!$@ place?"</strong>
I'll give a quick answer: it was proposed, but too late and in too
unorganized a fashion. Some sort of hashing will undoubtedly be
included in a future Standard.)
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<hr />
<h2><a name="2">Added members and types</a></h2>
<p>Some of the classes in the Standard Library have additional
publicly-available members, and some classes are themselves not in
the standard. Of those, some are intended purely for the implementors,
for example, additional typedefs. Those won't be described here
(or anywhere else).
</p>
<ul>
<li>The extensions added by SGI are so numerous that they have
<a href="sgiexts.html">their own page</a>. Since the SGI STL is no
longer actively maintained, we will try and keep this code working
ourselves.</li>
<li>3.0.x <code>filebuf</code>s have another ctor with this signature:
<br />
<code>basic_filebuf(__c_file_type*, ios_base::openmode, int_type);</code>
<br />This comes in very handy in a number of places, such as
attaching Unix sockets, pipes, and anything else which uses file
descriptors, into the IOStream buffering classes. The three
arguments are as follows:
<ul>
<li><code>__c_file_type* F </code>
// the __c_file_type typedef usually boils down to stdio's FILE
</li>
<li><code>ios_base::openmode M </code>
// same as all the other uses of openmode
</li>
<li><code>int_type B </code>
// buffer size, defaults to BUFSIZ if not specified
</li>
</ul>
For those wanting to use file descriptors instead of FILE*'s, I
invite you to contemplate the mysteries of C's <code>fdopen()</code>.
</li>
<li>In library snapshot 3.0.95 and later, <code>filebuf</code>s bring
back an old extension: the <code>fd()</code> member function. The
integer returned from this function can be used for whatever file
descriptors can be used for on your platform. Naturally, the
library cannot track what you do on your own with a file descriptor,
so if you perform any I/O directly, don't expect the library to be
aware of it.
</li>
<li>Beginning with 3.1, the extra <code>filebuf</code> constructor and
the <code>fd()</code> function were removed from the standard
filebuf. Instead, <code><ext/stdio_filebuf.h></code> contains
a derived class called <code>__gnu_cxx::stdio_filebuf</code>.
</li>
</ul>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<hr />
<h2><a name="3">Allocators (versions 3.0, 3.1, 3.2)</a></h2>
<p>Thread-safety, space efficiency, high speed, portability... this is a
mess. Where to begin?
</p>
<h3>The Rules</h3>
<p>The C++ standard only gives a few directives in this area:
</p>
<ul>
<li>When you add elements to a container, and the container must allocate
more memory to hold them, the container makes the request via its
<code>Allocator</code> template parameter. This includes adding
char's to the string class, which acts as a regular STL container
in this respect.
</li>
<li>The default <code>Allocator</code> of every container-of-T is
<code>std::allocator<T></code>.
</li>
<li>The interface of the <code>allocator<T></code> class is
extremely simple. It has about 20 public declarations (nested
typedefs, member functions, etc), but the two which concern us most
are:
<pre>
T* allocate (size_type n, const void* hint = 0);
void deallocate (T* p, size_type n);</pre>
(This is a simplicifcation; the real signatures use nested typedefs.)
The <code>"n"</code> arguments in both those functions is a
<em>count</em> of the number of T's to allocate space for,
<em>not their total size</em>.
</li>
<li>"The storage is obtained by calling
<code>::operator new(size_t)</code>, but it is unspecified when or
how often this function is called. The use of <code>hint</code>
is unspecified, but intended as an aid to locality if an
implementation so desires." [20.4.1.1]/6
</li>
</ul>
<h3>Problems and Possibilities</h3>
<p>The easiest way of fulfilling the requirements is to call operator new
each time a container needs memory, and to call operator delete each
time the container releases memory. <strong>BUT</strong>
<a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00105.html">this
method is horribly slow</a>.
</p>
<p>Or we can keep old memory around, and reuse it in a pool to save time.
The old libstdc++-v2 used a memory pool, and so do we. As of 3.0,
<a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00136.html">it's
on by default</a>. The pool is shared among all the containers in the
program: when your program's std::vector<int> gets cut in half
and frees a bunch of its storage, that memory can be reused by the
private std::list<WonkyWidget> brought in from a KDE library
that you linked against. And we don't have to call operators new and
delete to pass the memory on, either, which is a speed bonus.
<strong>BUT</strong>...
</p>
<p>What about threads? No problem: in a threadsafe environment, the
memory pool is manipulated atomically, so you can grow a container in
one thread and shrink it in another, etc. <strong>BUT</strong> what
if threads in libstdc++-v3 aren't set up properly?
<a href="../faq/index.html#5_6">That's been answered already</a>.
</p>
<p><strong>BUT</strong> what if you want to use your own allocator? What
if you plan on using a runtime-loadable version of malloc() which uses
shared telepathic anonymous mmap'd sections serializable over a
network, so that memory requests <em>should</em> go through malloc?
And what if you need to debug it?
</p>
<p>Well then:
</p>
<h3>Available allocators in namespace std</h3>
<p>First I'll describe the situation as it exists for the code which
was released in GCC 3.1 and 3.2. Then I'll describe the differences
for 3.0. The allocator classes also have source documentation,
which is described <a href="../documentation.html#4">here</a> (you
will need to retrieve the maintainer-level docs, as almost none of
these entities are in the ISO standard).
</p>
<p>As a general rule of thumb, users are not allowed to use names which
begin with an underscore. This means that to be portable between
compilers, none of the following may be used in your program directly.
(If you decide to be unportable, then you're free do do what you want,
but it's not our fault if stuff breaks.) They are presented here for
information for maintainers and contributors in addition to users.
</p>
<p>These classes are always available:
</p>
<ul>
<li><code>__new_alloc</code> simply wraps <code>::operator new</code>
and <code>::operator delete</code>.
</li>
<li><code>__malloc_alloc_template<int inst></code> simply wraps
<code>malloc</code> and <code>free</code>. There is also a hook
for an out-of-memory handler (for new/delete this is taken care of
elsewhere). The <code>inst</code> parameter is described below.
This class was called <code>malloc_alloc</code> in earlier versions.
</li>
<li><code>allocator<T></code> has already been described; it is
The Standard Allocator for instances of T. It uses the internal
<code>__alloc</code> typedef (see below) to satisy its requests.
</li>
<li><code>__simple_alloc<T,A></code> is a wrapper around another
allocator, A, which itself is an allocator for instances of T.
This is primarily used in an internal "allocator traits"
class which helps encapsulate the different styles of allocators.
</li>
<li><code>__debug_alloc<A></code> is also a wrapper around an
arbitrary allocator A. It passes on slightly increased size
requests to A, and uses the extra memory to store size information.
When a pointer is passed to <code>deallocate()</code>, the stored
size is checked, and assert() is used to guarantee they match.
</li>
<li><code>__allocator<T,A></code> is an adaptor. Many of these
allocator classes have a consistent yet non-standard interface.
Such classes can be changed to a conforming interface with this
wrapper: <code>__allocator<T, __alloc></code> is thus the
same as <code>allocator<T></code>.
</li>
</ul>
<p>An internal typedef, <code> __mem_interface </code>, is defined to be
<code>__new_alloc</code> by default.
</p>
<p>Normally,
<code> __default_alloc_template<bool thr, int inst> </code>
is also available. This is the high-speed pool, called the default
node allocator. The reusable memory is shared among identical
instantiations of
this type. It calls through <code>__mem_interface</code> to obtain
new memory when its lists run out. If a client container requests a
block larger than a certain threshold size, then the pool is bypassed,
and the allocate/deallocate request is passed to
<code>__mem_interface</code> directly.
</p>
<p>Its <code>inst</code> parameter is described below. The
<code>thr</code> boolean determines whether the pool should be
manipulated atomically or not. Two typedefs are provided:
<code>__alloc</code> is defined as this node allocator with thr=true,
and therefore is threadsafe, while <code>__single_client_alloc</code>
defines thr=false, and is slightly faster but unsafe for multiple
threads.
</p>
<p>(Note that the GCC thread abstraction layer allows us to provide safe
zero-overhead stubs for the threading routines, if threads were
disabled at configuration time. In this situation,
<code>__alloc</code> should not be noticably slower than
<code>__single_client_alloc</code>.)
</p>
<p>[Another threadsafe allocator where each thread keeps its own free
list, so that no locking is needed, might be described here.]
</p>
<h3>A cannon to swat a fly:<code> __USE_MALLOC</code></h3>
<p>If you've already read <a href="../23_containers/howto.html#3">this
advice</a> and decided to define this macro, then the situation changes
thusly:
</p>
<ol>
<li><code>__mem_interface</code>, and</li>
<li><code>__alloc</code>, and</li>
<li><code>__single_client_alloc</code> are all typedef'd to
<code>__malloc_alloc_template</code>.</li>
<li><code>__default_alloc_template</code> is no longer available.
At all. Anywhere.</li>
</ol>
<h3>Writing your own allocators</h3>
<p>Depending on your application (a specific program, a generic library,
etc), allocator classes tend to be one of two styles: "SGI"
or "standard". See the comments in stl_alloc.h for more
information on this crucial difference.
</p>
<p>At the bottom of that header is a helper type,
<code>_Alloc_traits</code>, and various specializations of it. This
allows the container classes to make possible compile-time
optimizations based on features of the allocator. You should provide
a specialization of this type for your allocator (doing so takes only
two or three statements).
</p>
<h3>Using non-default allocators</h3>
<p>You can specify different memory management schemes on a per-container
basis, by overriding the default <code>Allocator</code> template
parameter. For example, an easy
(but nonportable)
method of specifying that only malloc/free should be used instead of
the default node allocator is:
</p>
<pre>
std::list <my_type, std::__malloc_alloc_template<0> > my_malloc_based_list;</pre>
Likewise, a debugging form of whichever allocator is currently in use:
<pre>
std::deque <my_type, std::__debug_alloc<std::__alloc> > debug_deque;</pre>
<h3><code>inst</code></h3>
<p>The <code>__malloc_alloc_template</code> and
<code>__default_alloc_template</code> classes take an integer parameter,
called inst here. This number is completely unused.
</p>
<p>The point of the number is to allow multiple instantiations of the
classes without changing the semantics at all. All three of
</p>
<pre>
typedef __default_alloc_template<true,0> normal;
typedef __default_alloc_template<true,1> private;
typedef __default_alloc_template<true,42> also_private;</pre>
<p>behave exactly the same way. However, the memory pool for each type
(and remember that different instantiations result in different types)
remains separate.
</p>
<p>The library uses <strong>0</strong> in all its instantiations. If you
wish to keep separate free lists for a particular purpose, use a
different number.
</p>
<h3>3.0.x</h3>
<p>For 3.0.x, many of the names were incorrectly <em>not</em> prefixed
with underscores. So symbols such as "std::single_client_alloc"
are present. Be very careful to not depend on these names any more
than you would depend on implementation-only names.
</p>
<p>Certain macros like <code>_NOTHREADS</code> and <code>__STL_THREADS</code>
can affect the 3.0.x allocators. Do not use them. Those macros have
been completely removed for 3.1.
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<hr />
<h2><a name="6">Allocators (version 3.3)</a></h2>
<p>Changes are coming...
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<hr />
<h2><a name="4">Compile-time checks</a></h2>
<p>Currently libstdc++-v3 uses the concept checkers from the Boost
library to perform <a href="../19_diagnostics/howto.html#3">optional
compile-time checking</a> of template instantiations of the standard
containers. They are described in the linked-to page.
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<hr />
<h2><a name="5">LWG Issues</a></h2>
<p>Everybody's got issues. Even the C++ Standard Library.
</p>
<p>The Library Working Group, or LWG, is the ISO subcommittee responsible
for making changes to the library. They periodically publish an
Issues List containing problems and possible solutions. As they reach
a consensus on proposed solutions, we often incorporate the solution
into libstdc++-v3.
</p>
<p>Here are the issues which have resulted in code changes to the library.
The links are to the specific defect reports from a <strong>partial
copy</strong> of the Issues List. You can read the full version online
at the <a href="http://www.dkuug.dk/jtc1/sc22/wg21/">ISO C++
Committee homepage</a>, linked to on the
<a href="http://gcc.gnu.org/readings.html">GCC "Readings"
page</a>. If
you spend a lot of time reading the issues, we recommend downloading
the ZIP file and reading them locally.
</p>
<p>(NB: <strong>partial copy</strong> means that not all links within
the lwg-*.html pages will work.
Specifically, links to defect reports that have not been accorded full
DR status will probably break. Rather than trying to mirror the
entire issues list on our overworked web server, we recommend you go
to the LWG homepage instead.)
</p>
<p>
If a DR is not listed here, we may simply not have gotten to it yet;
feel free to submit a patch. Search the include/bits and src
directories for appearances of _GLIBCPP_RESOLVE_LIB_DEFECTS for
examples of style. Note that we usually do not make changes to the code
until an issue has reached <a href="lwg-active.html#DR">DR</a> status.
</p>
<dl>
<dt><a href="lwg-defects.html#5">5</a>:
<em>string::compare specification questionable</em>
</dt>
<dd>This should be two overloaded functions rather than a single function.
</dd>
<dt><a href="lwg-defects.html#17">17</a>:
<em>Bad bool parsing</em>
</dt>
<dd>Apparently extracting Boolean values was messed up...
</dd>
<dt><a href="lwg-defects.html#22">22</a>:
<em>Member open vs flags</em>
</dt>
<dd>Re-opening a file stream does <em>not</em> clear the state flags.
</dd>
<dt><a href="lwg-defects.html#25">25</a>:
<em>String operator<< uses width() value wrong</em>
</dt>
<dd>Padding issues.
</dd>
<dt><a href="lwg-defects.html#48">48</a>:
<em>Use of non-existent exception constructor</em>
</dt>
<dd>An instance of <code>ios_base::failure</code> is constructed instead.
</dd>
<dt><a href="lwg-defects.html#49">49</a>:
<em>Underspecification of ios_base::sync_with_stdio</em>
</dt>
<dd>The return type is the <em>previous</em> state of synchronization.
</dd>
<dt><a href="lwg-defects.html#50">50</a>:
<em>Copy constructor and assignment operator of ios_base</em>
</dt>
<dd>These members functions are declared <code>private</code> and are
thus inaccessible. Specifying the correct semantics of
"copying stream state" was deemed too complicated.
</dd>
<dt><a href="lwg-defects.html#68">68</a>:
<em>Extractors for char* should store null at end</em>
</dt>
<dd>And they do now. An editing glitch in the last item in the list of
[27.6.1.2.3]/7.
</dd>
<dt><a href="lwg-defects.html#74">74</a>:
<em>Garbled text for codecvt::do_max_length</em>
</dt>
<dd>The text of the standard was gibberish. Typos gone rampant.
</dd>
<dt><a href="lwg-defects.html#83">83</a>:
<em>string::npos vs. string::max_size()</em>
</dt>
<dd>Safety checks on the size of the string should test against
<code>max_size()</code> rather than <code>npos</code>.
</dd>
<dt><a href="lwg-defects.html#109">109</a>:
<em>Missing binders for non-const sequence elements</em>
</dt>
<dd>The <code>binder1st</code> and <code>binder2nd</code> didn't have an
<code>operator()</code> taking a non-const parameter.
</dd>
<dt><a href="lwg-defects.html#110">110</a>:
<em>istreambuf_iterator::equal not const</em>
</dt>
<dd>This was not a const member function. Note that the DR says to
replace the function with a const one; we have instead provided an
overloaded version with identical contents.
</dd>
<dt><a href="lwg-defects.html#117">117</a>:
<em>basic_ostream uses nonexistent num_put member functions</em>
</dt>
<dd><code>num_put::put()</code> was overloaded on the wrong types.
</dd>
<dt><a href="lwg-defects.html#118">118</a>:
<em>basic_istream uses nonexistent num_get member functions</em>
</dt>
<dd>Same as 117, but for <code>num_get::get()</code>.
</dd>
<dt><a href="lwg-defects.html#129">129</a>:
<em>Need error indication from seekp() and seekg()</em>
</dt>
<dd>These functions set <code>failbit</code> on error now.
</dd>
<dt><a href="lwg-defects.html#136">136</a>:
<em>seekp, seekg setting wrong streams?</em>
</dt>
<dd><code>seekp</code> should only set the output stream, and
<code>seekg</code> should only set the input stream.
</dd>
<!--<dt><a href="lwg-defects.html#159">159</a>:
<em>Strange use of underflow()</em>
</dt>
<dd>In fstream.tcc, the basic_filebuf<>::showmanyc() function
should probably not be calling <code>underflow()</code>.
</dd> -->
<dt><a href="lwg-active.html#167">167</a>:
<em>Improper use of traits_type::length()</em>
</dt>
<dd><code>op<<</code> with a <code>const char*</code> was
calculating an incorrect number of characters to write.
</dd>
<dt><a href="lwg-defects.html#181">181</a>:
<em>make_pair() unintended behavior</em>
</dt>
<dd>This function used to take its arguments as reference-to-const, now
it copies them (pass by value).
</dd>
<dt><a href="lwg-defects.html#195">195</a>:
<em>Should basic_istream::sentry's constructor ever set eofbit?</em>
</dt>
<dd>Yes, it can, specifically if EOF is reached while skipping whitespace.
</dd>
<dt><a href="lwg-defects.html#211">211</a>:
<em>operator>>(istream&, string&) doesn't set failbit</em>
</dt>
<dd>If nothing is extracted into the string, <code>op>></code> now
sets <code>failbit</code> (which can cause an exception, etc, etc).
</dd>
<dt><a href="lwg-defects.html#214">214</a>:
<em>set::find() missing const overload</em>
</dt>
<dd>Both <code>set</code> and <code>multiset</code> were missing
overloaded find, lower_bound, upper_bound, and equal_range functions
for const instances.
</dd>
<dt><a href="lwg-defects.html#251">251</a>:
<em>basic_stringbuf missing allocator_type</em>
</dt>
<dd>This nested typdef was originally not specified.
</dd>
<dt><a href="lwg-defects.html#265">265</a>:
<em>std::pair::pair() effects overly restrictive</em>
</dt>
<dd>The default ctor would build its members from copies of temporaries;
now it simply uses their respective default ctors.
</dd>
<dt><a href="lwg-defects.html#266">266</a>:
<em>bad_exception::~bad_exception() missing Effects clause</em>
</dt>
<dd>The <code>bad_</code>* classes no longer have destructors (they
are trivial), since no description of them was ever given.
</dd>
<dt><a href="lwg-defects.html#275">275</a>:
<em>Wrong type in num_get::get() overloads</em>
</dt>
<dd>Similar to 118.
</dd>
<!--
<dt><a href="lwg-defects.html#"></a>:
<em></em>
</dt>
<dd>
</dd>
-->
</dl>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<!-- ####################################################### -->
<hr />
<p class="fineprint"><em>
See <a href="../17_intro/license.html">license.html</a> for copying conditions.
Comments and suggestions are welcome, and may be sent to
<a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing list</a>.
</em></p>
</body>
</html>
|
