gcc/libstdc++-v3/docs/html/23_containers/howto.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<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="HOWTO for the libstdc++ chapter 23.">
   <meta NAME="GENERATOR" CONTENT="vi and eight fingers">
   <title>libstdc++-v3 HOWTO:  Chapter 23</title>
<link REL=StyleSheet HREF="../lib3styles.css">
</head>
<body>

<h1 CLASS="centered"><a name="top">Chapter 23:  Containers</a></h1>

<p>Chapter 23 deals with container classes and what they offer.
</p>


<!-- ####################################################### -->
<hr>
<h1>Contents</h1>
<ul>
   <li><a href="#1">Making code unaware of the container/array difference</a>
   <li><a href="#2">Variable-sized bitmasks</a>
   <li><a href="#3">Containers and multithreading</a>
   <li><a href="#4">&quot;Hinting&quot; during insertion</a>
   <li><a href="#5">Bitmasks and string arguments</a>
</ul>

<hr>

<!-- ####################################################### -->

<h2><a name="1">Making code unaware of the container/array difference</a></h2>
   <p>You're writing some code and can't decide whether to use builtin
      arrays or some kind of container.  There are compelling reasons 
      to use one of the container classes, but you're afraid that you'll
      eventually run into difficulties, change everything back to arrays,
      and then have to change all the code that uses those data types to
      keep up with the change.
   </p>
   <p>If your code makes use of the standard algorithms, this isn't as
      scary as it sounds.  The algorithms don't know, nor care, about
      the kind of &quot;container&quot; on which they work, since the
      algorithms are only given endpoints to work with.  For the container
      classes, these are iterators (usually <code>begin()</code> and
      <code>end()</code>, but not always).  For builtin arrays, these are
      the address of the first element and the
      <a href="../24_iterators/howto.html#2">past-the-end</a> element.
   </p>
   <p>Some very simple wrapper functions can hide all of that from the
      rest of the code.  For example, a pair of functions called
      <code>beginof</code> can be written, one that takes an array, another
      that takes a vector.  The first returns a pointer to the first
      element, and the second returns the vector's <code>begin()</code>
      iterator.
   </p>
   <p>The functions should be made template functions, and should also 
      be declared inline.  As pointed out in the comments in the code 
      below, this can lead to <code>beginof</code> being optimized out of
      existence, so you pay absolutely nothing in terms of increased
      code size or execution time.
   </p>
   <p>The result is that if all your algorithm calls look like
      <PRE>
   std::transform(beginof(foo), endof(foo), beginof(foo), SomeFunction);</PRE>
      then the type of foo can change from an array of ints to a vector
      of ints to a deque of ints and back again, without ever changing any
      client code.
   </p>
   <p>This author has a collection of such functions, called &quot;*of&quot;
      because they all extend the builtin &quot;sizeof&quot;.  It started
      with some Usenet discussions on a transparent way to find the length
      of an array.  A simplified and much-reduced version for easier
      reading is <a href="wrappers_h.txt">given here</a>.
   </p>
   <p>Astute readers will notice two things at once:  first, that the
      container class is still a <code>vector&lt;T&gt;</code> instead of a
      more general <code>Container&lt;T&gt;</code>.  This would mean that
      three functions for <code>deque</code> would have to be added, another
      three for <code>list</code>, and so on.  This is due to problems with
      getting template resolution correct; I find it easier just to 
      give the extra three lines and avoid confusion.
   </p>
   <p>Second, the line
      <PRE>
    inline unsigned int lengthof (T (&amp;)[sz]) { return sz; } </PRE>
      looks just weird!  Hint:  unused parameters can be left nameless.
   </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">Variable-sized bitmasks</a></h2>
   <p>No, you cannot write code of the form
      <!-- Careful, the leading spaces in PRE show up directly. -->
      <PRE>
      #include &lt;bitset&gt;

      void foo (size_t n)
      {
          std::bitset&lt;n&gt;   bits;
          ....
      } </PRE>
      because <code>n</code> must be known at compile time.  Your compiler is
      correct; it is not a bug.  That's the way templates work.  (Yes, it
      <em>is</em> a feature.)
   </p>
   <p>There are a couple of ways to handle this kind of thing.  Please
      consider all of them before passing judgement.  They include, in
      no particular order:
      <ul>
        <li>A very large N in <code>bitset&lt;N&gt;</code>.
        <li>A container&lt;bool&gt;.
        <li>Extremely weird solutions.
      </ul>
   </p>
   <p><B>A very large N in <code>bitset&lt;N&gt;</code>.&nbsp;&nbsp;</B>  It has
      been pointed out a few times in newsgroups that N bits only takes up
      (N/8) bytes on most systems, and division by a factor of eight is pretty
      impressive when speaking of memory.  Half a megabyte given over to a
      bitset (recall that there is zero space overhead for housekeeping info;
      it is known at compile time exactly how large the set is) will hold over
      four million bits.  If you're using those bits as status flags (e.g.,
      &quot;changed&quot;/&quot;unchanged&quot; flags), that's a <em>lot</em>
      of state.
   </p>
   <p>You can then keep track of the &quot;maximum bit used&quot; during some
      testing runs on representative data, make note of how many of those bits
      really need to be there, and then reduce N to a smaller number.  Leave
      some extra space, of course.  (If you plan to write code like the 
      incorrect example above, where the bitset is a local variable, then you
      may have to talk your compiler into allowing that much stack space;
      there may be zero space overhead, but it's all allocated inside the
      object.)
   </p>
   <p><B>A container&lt;bool&gt;.&nbsp;&nbsp;</B>  The Committee made provision
      for the space savings possible with that (N/8) usage previously mentioned,
      so that you don't have to do wasteful things like
      <code>Container&lt;char&gt;</code> or
      <code>Container&lt;short int&gt;</code>.
      Specifically, <code>vector&lt;bool&gt;</code> is required to be
      specialized for that space savings.
   </p>
   <p>The problem is that <code>vector&lt;bool&gt;</code> doesn't behave like a
      normal vector anymore.  There have been recent journal articles which
      discuss the problems (the ones by Herb Sutter in the May and
      July/August 1999 issues of
      <em>C++ Report</em> cover it well).  Future revisions of the ISO C++
      Standard will change the requirement for <code>vector&lt;bool&gt;</code>
      specialization.  In the meantime, <code>deque&lt;bool&gt;</code> is
      recommended (although its behavior is sane, you probably will not get
      the space savings, but the allocation scheme is different than that
      of vector).
   </p>
   <p><B>Extremely weird solutions.&nbsp;&nbsp;</B>  If you have access to
      the compiler and linker at runtime, you can do something insane, like
      figuring out just how many bits you need, then writing a temporary 
      source code file.  That file contains an instantiation of
      <code>bitset</code>
      for the required number of bits, inside some wrapper functions with
      unchanging signatures.  Have your program then call the
      compiler on that file using Position Independant Code, then open the
      newly-created object file and load those wrapper functions.  You'll have
      an instantiation of <code>bitset&lt;N&gt;</code> for the exact
      <code>N</code>
      that you need at the time.  Don't forget to delete the temporary files.
      (Yes, this <em>can</em> be, and <em>has been</em>, done.)
   </p>
   <!-- I wonder if this next paragraph will get me in trouble... -->
   <p>This would be the approach of either a visionary genius or a raving
      lunatic, depending on your programming and management style.  Probably
      the latter.
   </p>
   <p>Which of the above techniques you use, if any, are up to you and your
      intended application.  Some time/space profiling is indicated if it
      really matters (don't just guess).  And, if you manage to do anything
      along the lines of the third category, the author would love to hear
      from you...
   </p>
   <p>Also note that the implementation of bitset used in libstdc++-v3 has
      <a href="../ext/sgiexts.html#ch23">some extensions</a>.
   </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="3">Containers and multithreading</a></h2>
   <p>This section will mention some of the problems in designing MT
      programs that use Standard containers.  For information on other
      aspects of multithreading (e.g., the library as a whole), see
      the Received Wisdom on Chapter 17.  This section only applies
      when gcc and libstdc++-v3 were configured with --enable-threads.
   </p>
   <p>Two excellent pages to read when working with templatized containers
      and threads are
      <a href="http://www.sgi.com/tech/stl/thread_safety.html">SGI's
      http://www.sgi.com/tech/stl/thread_safety.html</a> and
      <a href="http://www.sgi.com/tech/stl/Allocators.html">SGI's
      http://www.sgi.com/tech/stl/Allocators.html</a>.  The
      libstdc++-v3 uses the same definition of thread safety
      when discussing design.  A key point that beginners may miss is the
      fourth major paragraph of the first page mentioned above
      (&quot;For most clients,&quot;...), pointing
      out that locking must nearly always be done outside the container,
      by client code (that'd be you, not us *grin*).
      <em>However, please take caution when considering the discussion
      about the user-level configuration of the mutex lock
      implementation inside the STL container-memory allocator on that
      page.  For the sake of this discussion, libstdc++-v3 configures
      the SGI STL implementation, not you.  We attempt to configure
      the mutex lock as is best for your platform.  In particular,
      past advice was for people using g++ to explicitly define
      _PTHREADS on the command line to get a thread-safe STL.  This
      is no longer required for your port.  It may or may not be
      a good idea for your port.  Extremely big caution: if you
      compile some of your application code against the STL with one
      set of threading flags and macros and another portion of the
      code with different flags and macros that influence the
      selection of the mutex lock, you may well end up with multiple
      locking mechanisms in use which don't impact each other in the
      manner that they should.  Everything might link and all code
      might have been built with a perfectly reasonable thread model
      but you may have two internal ABIs in play within the
      application.  This might produce races, memory leaks and fatal
      crashes.  In any multithreaded application using STL, this
      is the first thing to study well before blaming the allocator.</em>
   </p>
   <p>You didn't read it, did you?  *sigh*  I'm serious, go read the
      SGI page.  It's really good and doesn't take long, and makes most
      of the points that would otherwise have to be made here (and does
      a better job).
   </p>
   <p>That's much better.  Now, the issue of MT has been brought up on
      the libstdc++-v3 mailing list as well as the main GCC mailing list
      several times.  The Chapter 17 HOWTO has some links into the mail
      archives, so you can see what's been thrown around.  The usual
      container (or pseudo-container, depending on how you look at it)
      that people have in mind is <code>string</code>, which is one of the
      points where libstdc++ departs from the SGI STL.  As of the
      2.90.8 snapshot, the libstdc++-v3 string class is safe for
      certain kinds of multithreaded access.
   </p>
   <p>For implementing a container which does its own locking, it is
      trivial to (as SGI suggests) provide a wrapper class which obtains
      the lock, performs the container operation, then releases the lock.
      This could be templatized <em>to a certain extent</em>, on the
      underlying container and/or a locking mechanism.  Trying to provide
      a catch-all general template solution would probably be more trouble
      than it's worth.
   </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">&quot;Hinting&quot; during insertion</a></h2>
   <p>Section [23.1.2], Table 69, of the C++ standard lists this function
      for all of the associative containers (map, set, etc):
      <PRE>
      a.insert(p,t);</PRE>
      where 'p' is an iterator into the container 'a', and 't' is the item
      to insert.  The standard says that &quot;iterator p is a hint
      pointing to where the insert should start to search,&quot; but
      specifies nothing more.  (LWG Issue #233, currently in review,
      addresses this topic, but I will ignore it here because it is not yet
      finalized.)
   </p>
   <p>Here we'll describe how the hinting works in the libstdc++-v3
      implementation, and what you need to do in order to take advantage of
      it.  (Insertions can change from logarithmic complexity to amortized
      constant time, if the hint is properly used.)  Also, since the current
      implementation is based on the SGI STL one, these points may hold true
      for other library implementations also, since the HP/SGI code is used
      in a lot of places.
   </p>
   <p>In the following text, the phrases <em>greater than</em> and <em>less
      than</em> refer to the results of the strict weak ordering imposed on
      the container by its comparison object, which defaults to (basically)
      &quot;&lt;&quot;.  Using those phrases is semantically sloppy, but I
      didn't want to get bogged down in syntax.  I assume that if you are
      intelligent enough to use your own comparison objects, you are also
      intelligent enough to assign &quot;greater&quot; and &quot;lesser&quot;
      their new meanings in the next paragraph.  *grin*
   </p>
   <p>If the <code>hint</code> parameter ('p' above) is equivalent to:
     <ul>
      <li><code>begin()</code>, then the item being inserted should have a key
          less than all the other keys in the container.  The item will
          be inserted at the beginning of the container, becoming the new
          entry at <code>begin()</code>.
      <li><code>end()</code>, then the item being inserted should have a key
          greater than all the other keys in the container.  The item will
          be inserted at the end of the container, becoming the new entry
          at <code>end()</code>.
      <li>neither <code>begin()</code> nor <code>end()</code>, then:  Let <code>h</code>
          be the entry in the container pointed to by <code>hint</code>, that
          is, <code>h = *hint</code>.  Then the item being inserted should have
          a key less than that of <code>h</code>, and greater than that of the
          item preceeding <code>h</code>.  The new item will be inserted
          between <code>h</code> and <code>h</code>'s predecessor.
     </ul>
   </p>
   <p>For <code>multimap</code> and <code>multiset</code>, the restrictions are
      slightly looser:  &quot;greater than&quot; should be replaced by
      &quot;not less than&quot; and &quot;less than&quot; should be replaced
      by &quot;not greater than.&quot;  (Why not replace greater with
      greater-than-or-equal-to?  You probably could in your head, but the
      mathematicians will tell you that it isn't the same thing.)
   </p>
   <p>If the conditions are not met, then the hint is not used, and the
      insertion proceeds as if you had called <code> a.insert(t) </code>
      instead.  (<strong>Note </strong> that GCC releases prior to 3.0.2
      had a bug in the case with <code>hint == begin()</code> for the
      <code>map</code> and <code>set</code> classes.  You should not use a hint
      argument in those releases.)
   </p>
   <p>This behavior goes well with other container's <code>insert()</code>
      functions which take an iterator:  if used, the new item will be
      inserted before the iterator passed as an argument, same as the other
      containers.  The exception
      (in a sense) is with a hint of <code>end()</code>:  the new item will
      actually be inserted after <code>end()</code>, but it also becomes the
      new <code>end()</code>.
   </p>
   <p><strong>Note </strong> also that the hint in this implementation is a
      one-shot.  The insertion-with-hint routines check the immediately
      surrounding entries to ensure that the new item would in fact belong
      there.  If the hint does not point to the correct place, then no
      further local searching is done; the search begins from scratch in
      logarithmic time.  (Further local searching would only increase the
      time required when the hint is too far off.)
   </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">Bitmasks and string arguments</a></h2>
   <p>Bitmasks do not take char* nor const char* arguments in their
      constructors.  This is something of an accident, but you can read
      about the problem:  follow the library's &quot;Links&quot; from the
      homepage, and from the C++ information &quot;defect reflector&quot;
      link, select the library issues list.  Issue number 116 describes the
      problem.
   </p>
   <p>For now you can simply make a temporary string object using the
      constructor expression:
      <PRE>
      std::bitset&lt;5&gt; b ( std::string(&quot;10110&quot;) );
      </PRE>
      instead of
      <PRE>
      std::bitset&lt;5&gt; b ( &quot;10110&quot; );    // invalid
      </PRE>
   </p>
   <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>
Comments and suggestions are welcome, and may be sent to
<a href="mailto:libstdc++@gcc.gnu.org">the mailing list</a>.
</em></p>


</body>
</html>