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, 3.3)</a></li>
  45    <li><a href="#6">Allocators (version 3.4)</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/tech/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/tech/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, 3.3)</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.4)</a></h2>
 365    <p>Changes are coming...
 366    </p>
 367    <p>If you plan on writing your own allocators,
 368       <a href="../documentation.html#4">source documentation</a> is
 369       available.  You'll need to get the &quot;maintainers&quot; collection
 370       in order to see the helper classes and extra notes.
 371    </p>
 372    <p>Return <a href="#top">to top of page</a> or
 373       <a href="../faq/index.html">to the FAQ</a>.
 374    </p>
 375
 376 <hr />
 377 <h2><a name="4">Compile-time checks</a></h2>
 378    <p>Currently libstdc++-v3 uses the concept checkers from the Boost
 379       library to perform <a href="../19_diagnostics/howto.html#3">optional
 380       compile-time checking</a> of template instantiations of the standard
 381       containers.  They are described in the linked-to page.
 382    </p>
 383    <p>Return <a href="#top">to top of page</a> or
 384       <a href="../faq/index.html">to the FAQ</a>.
 385    </p>
 386
 387 <hr />
 388 <h2><a name="5">LWG Issues</a></h2>
 389    <p>Everybody's got issues.  Even the C++ Standard Library.
 390    </p>
 391    <p>The Library Working Group, or LWG, is the ISO subcommittee responsible
 392       for making changes to the library.  They periodically publish an
 393       Issues List containing problems and possible solutions.  As they reach
 394       a consensus on proposed solutions, we often incorporate the solution
 395       into libstdc++-v3.
 396    </p>
 397    <p>Here are the issues which have resulted in code changes to the library.
 398       The links are to the specific defect reports from a <strong>partial
 399       copy</strong> of the Issues List.  You can read the full version online
 400       at the <a href="http://www.dkuug.dk/jtc1/sc22/wg21/">ISO C++
 401       Committee homepage</a>, linked to on the
 402       <a href="http://gcc.gnu.org/readings.html">GCC &quot;Readings&quot;
 403       page</a>.  If
 404       you spend a lot of time reading the issues, we recommend downloading
 405       the ZIP file and reading them locally.
 406    </p>
 407    <p>(NB:  <strong>partial copy</strong> means that not all links within
 408       the lwg-*.html pages will work.
 409       Specifically, links to defect reports that have not been accorded full
 410       DR status will probably break.  Rather than trying to mirror the
 411       entire issues list on our overworked web server, we recommend you go
 412       to the LWG homepage instead.)
 413    </p>
 414    <p>
 415       If a DR is not listed here, we may simply not have gotten to it yet;
 416       feel free to submit a patch.  Search the include/bits and src
 417       directories for appearances of _GLIBCXX_RESOLVE_LIB_DEFECTS for
 418       examples of style.  Note that we usually do not make changes to the code
 419       until an issue has reached <a href="lwg-active.html#DR">DR</a> status.
 420    </p>
 421    <dl>
 422     <dt><a href="lwg-defects.html#5">5</a>:
 423         <em>string::compare specification questionable</em>
 424     </dt>
 425     <dd>This should be two overloaded functions rather than a single function.
 426     </dd>
 427
 428     <dt><a href="lwg-defects.html#17">17</a>:
 429         <em>Bad bool parsing</em>
 430     </dt>
 431     <dd>Apparently extracting Boolean values was messed up...
 432     </dd>
 433
 434     <dt><a href="lwg-defects.html#19">19</a>:
 435         <em>&quot;Noconv&quot; definition too vague</em>
 436     </dt>
 437     <dd>If <code>codecvt::do_in</code> returns <code>noconv</code> there are
 438         no changes to the values in <code>[to, to_limit)</code>.
 439     </dd>
 440
 441     <dt><a href="lwg-defects.html#22">22</a>:
 442         <em>Member open vs flags</em>
 443     </dt>
 444     <dd>Re-opening a file stream does <em>not</em> clear the state flags.
 445     </dd>
 446
 447     <dt><a href="lwg-defects.html#25">25</a>:
 448         <em>String operator&lt;&lt; uses width() value wrong</em>
 449     </dt>
 450     <dd>Padding issues.
 451     </dd>
 452
 453     <dt><a href="lwg-defects.html#48">48</a>:
 454         <em>Use of non-existent exception constructor</em>
 455     </dt>
 456     <dd>An instance of <code>ios_base::failure</code> is constructed instead.
 457     </dd>
 458
 459     <dt><a href="lwg-defects.html#49">49</a>:
 460         <em>Underspecification of ios_base::sync_with_stdio</em>
 461     </dt>
 462     <dd>The return type is the <em>previous</em> state of synchronization.
 463     </dd>
 464
 465     <dt><a href="lwg-defects.html#50">50</a>:
 466         <em>Copy constructor and assignment operator of ios_base</em>
 467     </dt>
 468     <dd>These members functions are declared <code>private</code> and are
 469         thus inaccessible.  Specifying the correct semantics of
 470         &quot;copying stream state&quot; was deemed too complicated.
 471     </dd>
 472
 473     <dt><a href="lwg-defects.html#60">60</a>:
 474         <em>What is a formatted input function?</em>
 475     </dt>
 476     <dd>This DR made many widespread changes to <code>basic_istream</code>,
 477         not all of which have been implemented.
 478     </dd>
 479
 480     <dt><a href="lwg-defects.html#68">68</a>:
 481         <em>Extractors for char* should store null at end</em>
 482     </dt>
 483     <dd>And they do now.  An editing glitch in the last item in the list of
 484         [27.6.1.2.3]/7.
 485     </dd>
 486
 487     <dt><a href="lwg-defects.html#74">74</a>:
 488         <em>Garbled text for codecvt::do_max_length</em>
 489     </dt>
 490     <dd>The text of the standard was gibberish.  Typos gone rampant.
 491     </dd>
 492
 493     <dt><a href="lwg-defects.html#83">83</a>:
 494         <em>string::npos vs. string::max_size()</em>
 495     </dt>
 496     <dd>Safety checks on the size of the string should test against
 497         <code>max_size()</code> rather than <code>npos</code>.
 498     </dd>
 499
 500     <dt><a href="lwg-defects.html#90">90</a>:
 501         <em>Incorrect description of operator&gt;&gt; for strings</em>
 502     </dt>
 503     <dd>The effect contain <code>isspace(c,getloc())</code> which must be
 504         replaced by <code>isspace(c,is.getloc())</code>.
 505     </dd>
 506
 507     <dt><a href="lwg-defects.html#109">109</a>:
 508         <em>Missing binders for non-const sequence elements</em>
 509     </dt>
 510     <dd>The <code>binder1st</code> and <code>binder2nd</code> didn't have an
 511         <code>operator()</code> taking a non-const parameter.
 512     </dd>
 513
 514     <dt><a href="lwg-defects.html#110">110</a>:
 515         <em>istreambuf_iterator::equal not const</em>
 516     </dt>
 517     <dd>This was not a const member function.  Note that the DR says to
 518         replace the function with a const one; we have instead provided an
 519         overloaded version with identical contents.
 520     </dd>
 521
 522     <dt><a href="lwg-defects.html#117">117</a>:
 523         <em>basic_ostream uses nonexistent num_put member functions</em>
 524     </dt>
 525     <dd><code>num_put::put()</code> was overloaded on the wrong types.
 526     </dd>
 527
 528     <dt><a href="lwg-defects.html#118">118</a>:
 529         <em>basic_istream uses nonexistent num_get member functions</em>
 530     </dt>
 531     <dd>Same as 117, but for <code>num_get::get()</code>.
 532     </dd>
 533
 534     <dt><a href="lwg-defects.html#129">129</a>:
 535         <em>Need error indication from seekp() and seekg()</em>
 536     </dt>
 537     <dd>These functions set <code>failbit</code> on error now.
 538     </dd>
 539
 540     <dt><a href="lwg-defects.html#136">136</a>:
 541         <em>seekp, seekg setting wrong streams?</em>
 542     </dt>
 543     <dd><code>seekp</code> should only set the output stream, and
 544         <code>seekg</code> should only set the input stream.
 545     </dd>
 546
 547 <!--<dt><a href="lwg-defects.html#159">159</a>:
 548         <em>Strange use of underflow()</em>
 549     </dt>
 550     <dd>In fstream.tcc, the basic_filebuf&lt;&gt;::showmanyc() function
 551         should probably not be calling <code>underflow()</code>.
 552     </dd> -->
 553
 554     <dt><a href="lwg-active.html#167">167</a>:
 555         <em>Improper use of traits_type::length()</em>
 556     </dt>
 557     <dd><code>op&lt;&lt;</code> with a <code>const char*</code> was
 558         calculating an incorrect number of characters to write.
 559     </dd>
 560
 561     <dt><a href="lwg-defects.html#171">171</a>:
 562         <em>Strange seekpos() semantics due to joint position</em>
 563     </dt>
 564     <dd>Quite complex to summarize...
 565     </dd>
 566
 567     <dt><a href="lwg-defects.html#181">181</a>:
 568         <em>make_pair() unintended behavior</em>
 569     </dt>
 570     <dd>This function used to take its arguments as reference-to-const, now
 571         it copies them (pass by value).
 572     </dd>
 573
 574     <dt><a href="lwg-defects.html#195">195</a>:
 575         <em>Should basic_istream::sentry's constructor ever set eofbit?</em>
 576     </dt>
 577     <dd>Yes, it can, specifically if EOF is reached while skipping whitespace.
 578     </dd>
 579
 580     <dt><a href="lwg-defects.html#211">211</a>:
 581         <em>operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</em>
 582     </dt>
 583     <dd>If nothing is extracted into the string, <code>op&gt;&gt;</code> now
 584         sets <code>failbit</code> (which can cause an exception, etc, etc).
 585     </dd>
 586
 587     <dt><a href="lwg-defects.html#214">214</a>:
 588         <em>set::find() missing const overload</em>
 589     </dt>
 590     <dd>Both <code>set</code> and <code>multiset</code> were missing
 591         overloaded find, lower_bound, upper_bound, and equal_range functions
 592         for const instances.
 593     </dd>
 594
 595     <dt><a href="lwg-active.html#231">231</a>:
 596         <em>Precision in iostream?</em>
 597     </dt>
 598     <dd>For conversion from a floating-point type, <code>str.precision()</code>
 599         is specified in the conversion specification.
 600     </dd>
 601
 602     <dt><a href="lwg-defects.html#235">235</a>:
 603         <em>No specification of default ctor for reverse_iterator</em>
 604     </dt>
 605     <dd>The declaration of <code>reverse_iterator</code> lists a default constructor.
 606         However, no specification is given what this constructor should do.
 607     </dd>
 608
 609     <dt><a href="lwg-defects.html#251">251</a>:
 610         <em>basic_stringbuf missing allocator_type</em>
 611     </dt>
 612     <dd>This nested typdef was originally not specified.
 613     </dd>
 614
 615     <dt><a href="lwg-defects.html#265">265</a>:
 616         <em>std::pair::pair() effects overly restrictive</em>
 617     </dt>
 618     <dd>The default ctor would build its members from copies of temporaries;
 619         now it simply uses their respective default ctors.
 620     </dd>
 621
 622     <dt><a href="lwg-defects.html#266">266</a>:
 623         <em>bad_exception::~bad_exception() missing Effects clause</em>
 624     </dt>
 625     <dd>The <code>bad_</code>* classes no longer have destructors (they
 626         are trivial), since no description of them was ever given.
 627     </dd>
 628
 629     <dt><a href="lwg-defects.html#271">271</a>:
 630         <em>basic_iostream missing typedefs</em>
 631     </dt>
 632     <dd>The typedefs it inherits from its base classes can't be used, since
 633         (for example) <code>basic_iostream&lt;T&gt;::traits_type</code> is ambiguous.
 634     </dd>
 635
 636     <dt><a href="lwg-defects.html#275">275</a>:
 637         <em>Wrong type in num_get::get() overloads</em>
 638     </dt>
 639     <dd>Similar to 118.
 640     </dd>
 641
 642 <!--
 643     <dt><a href="lwg-defects.html#"></a>:
 644         <em></em>
 645     </dt>
 646     <dd>
 647     </dd>
 648
 649 -->
 650    </dl>
 651    <p>Return <a href="#top">to top of page</a> or
 652       <a href="../faq/index.html">to the FAQ</a>.
 653    </p>
 654
 655
 656 <!-- ####################################################### -->
 657
 658 <hr />
 659 <p class="fineprint"><em>
 660 See <a href="../17_intro/license.html">license.html</a> for copying conditions.
 661 Comments and suggestions are welcome, and may be sent to
 662 <a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing list</a>.
 663 </em></p>
 664
 665
 666 </body>
 667 </html>