libstdc++-v3/docs/html/ext/howto.html

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