libstdc++-v3/doc/html/manual/associative.html - gcc - Git at Google

 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Associative</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="containers.html" title="Chapter 9.  Containers" /><link rel="prev" href="containers.html" title="Chapter 9.  Containers" /><link rel="next" href="unordered_associative.html" title="Unordered Associative" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Associative</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="containers.html">Prev</a> </td><th width="60%" align="center">Chapter 9.
   Containers

 </th><td width="20%" align="right"> <a accesskey="n" href="unordered_associative.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="std.containers.associative"></a>Associative</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="containers.associative.insert_hints"></a>Insertion Hints</h3></div></div></div><p>
      Section [23.1.2], Table 69, of the C++ standard lists this
      function for all of the associative containers (map, set, etc):
    </p><pre class="programlisting">
       a.insert(p,t);
    </pre><p>
      where 'p' is an iterator into the container 'a', and 't' is the
      item to insert.  The standard says that <span class="quote">“<span class="quote"><code class="code">t</code> is
      inserted as close as possible to the position just prior to
      <code class="code">p</code>.</span>”</span> (Library DR #233 addresses this topic,
      referring to <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html" target="_top">N1780</a>.
      Since version 4.2 GCC implements the resolution to DR 233, so
      that insertions happen as close as possible to the hint. For
      earlier releases the hint was only used as described below.
    </p><p>
      Here we'll describe how the hinting works in the libstdc++
      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 <span class="emphasis"><em>greater
      than</em></span> and <span class="emphasis"><em>less than</em></span> refer to the
      results of the strict weak ordering imposed on the container by
      its comparison object, which defaults to (basically)
      <span class="quote">“<span class="quote">&lt;</span>”</span>.  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 <span class="quote">“<span class="quote">greater</span>”</span>
      and <span class="quote">“<span class="quote">lesser</span>”</span> their new meanings in the next
      paragraph.  *grin*
    </p><p>
      If the <code class="code">hint</code> parameter ('p' above) is equivalent to:
    </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
 	  <code class="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 class="code">begin()</code>.
       </p></li><li class="listitem"><p>
 	  <code class="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 before <code class="code">end()</code>.
       </p></li><li class="listitem"><p>
 	  neither <code class="code">begin()</code> nor <code class="code">end()</code>, then:
 	  Let <code class="code">h</code> be the entry in the container pointed to
 	  by <code class="code">hint</code>, that is, <code class="code">h = *hint</code>.  Then
 	  the item being inserted should have a key less than that of
 	  <code class="code">h</code>, and greater than that of the item preceding
 	  <code class="code">h</code>.  The new item will be inserted between
 	  <code class="code">h</code> and <code class="code">h</code>'s predecessor.
 	  </p></li></ul></div><p>
      For <code class="code">multimap</code> and <code class="code">multiset</code>, the
      restrictions are slightly looser: <span class="quote">“<span class="quote">greater than</span>”</span>
      should be replaced by <span class="quote">“<span class="quote">not less than</span>”</span>and <span class="quote">“<span class="quote">less
      than</span>”</span> should be replaced by <span class="quote">“<span class="quote">not greater
      than.</span>”</span> (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 class="code"> a.insert(t)
      </code> instead.  (<span class="emphasis"><em>Note </em></span> that GCC releases
      prior to 3.0.2 had a bug in the case with <code class="code">hint ==
      begin()</code> for the <code class="code">map</code> and <code class="code">set</code>
      classes.  You should not use a hint argument in those releases.)
    </p><p>
      This behavior goes well with other containers'
      <code class="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.
    </p><p>
      <span class="emphasis"><em>Note </em></span> also that the hint in this
      implementation is a one-shot.  The older 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.
    </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="containers.associative.bitset"></a>bitset</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="associative.bitset.size_variable"></a>Size Variable</h4></div></div></div><p>
 	No, you cannot write code of the form
       </p><pre class="programlisting">
       #include &lt;bitset&gt;

       void foo (size_t n)
       {
 	  std::bitset&lt;n&gt;   bits;
 	  ....
       }
    </pre><p>
      because <code class="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 <span class="emphasis"><em>is</em></span> 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:
    </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>A very large N in <code class="code">bitset&lt;N&gt;</code>.</p></li><li class="listitem"><p>A container&lt;bool&gt;.</p></li><li class="listitem"><p>Extremely weird solutions.</p></li></ul></div><p>
      <span class="emphasis"><em>A very large N in
      <code class="code">bitset&lt;N&gt;</code>.  </em></span> 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.,
      <span class="quote">“<span class="quote">changed</span>”</span>/<span class="quote">“<span class="quote">unchanged</span>”</span> flags), that's a
      <span class="emphasis"><em>lot</em></span> of state.
    </p><p>
      You can then keep track of the <span class="quote">“<span class="quote">maximum bit used</span>”</span>
      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>
      <span class="emphasis"><em>A container&lt;bool&gt;.  </em></span> 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 class="code">Container&lt;char&gt;</code> or
      <code class="code">Container&lt;short int&gt;</code>.  Specifically,
      <code class="code">vector&lt;bool&gt;</code> is required to be specialized for
      that space savings.
    </p><p>
      The problem is that <code class="code">vector&lt;bool&gt;</code> doesn't
      behave like a normal vector anymore.  There have been
      journal articles which discuss the problems (the ones by Herb
      Sutter in the May and July/August 1999 issues of C++ Report cover
      it well).  Future revisions of the ISO C++ Standard will change
      the requirement for <code class="code">vector&lt;bool&gt;</code>
      specialization.  In the meantime, <code class="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>
      <span class="emphasis"><em>Extremely weird solutions.  </em></span> 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 class="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 Independent Code, then open the newly-created object
      file and load those wrapper functions.  You'll have an
      instantiation of <code class="code">bitset&lt;N&gt;</code> for the exact
      <code class="code">N</code> that you need at the time.  Don't forget to delete
      the temporary files.  (Yes, this <span class="emphasis"><em>can</em></span> be, and
      <span class="emphasis"><em>has been</em></span>, done.)
    </p><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++ has
      <a class="link" href="ext_containers.html#manual.ext.containers.sgi" title="Backwards Compatibility">some extensions</a>.
    </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="associative.bitset.type_string"></a>Type String</h4></div></div></div><p>
       </p><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 <span class="quote">“<span class="quote">Links</span>”</span> from
      the homepage, and from the C++ information <span class="quote">“<span class="quote">defect
      reflector</span>”</span> 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:
    </p><pre class="programlisting">
       std::bitset&lt;5&gt; b ( std::string("10110") );
    </pre><p>
      instead of
    </p><pre class="programlisting">
       std::bitset&lt;5&gt; b ( "10110" );    // invalid
     </pre></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="containers.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="containers.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="unordered_associative.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 9.
   Containers

  </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Unordered Associative</td></tr></table></div></body></html>
	<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Associative</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="containers.html" title="Chapter 9. Containers" /><link rel="prev" href="containers.html" title="Chapter 9. Containers" /><link rel="next" href="unordered_associative.html" title="Unordered Associative" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Associative</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="containers.html">Prev</a> </td><th width="60%" align="center">Chapter 9.
	Containers

	</th><td width="20%" align="right"> <a accesskey="n" href="unordered_associative.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="std.containers.associative"></a>Associative</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="containers.associative.insert_hints"></a>Insertion Hints</h3></div></div></div><p>
	Section [23.1.2], Table 69, of the C++ standard lists this
	function for all of the associative containers (map, set, etc):
	</p><pre class="programlisting">
	a.insert(p,t);
	</pre><p>
	where 'p' is an iterator into the container 'a', and 't' is the
	item to insert. The standard says that <span class="quote">“<span class="quote"><code class="code">t</code> is
	inserted as close as possible to the position just prior to
	<code class="code">p</code>.</span>”</span> (Library DR #233 addresses this topic,
	referring to <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html" target="_top">N1780</a>.
	Since version 4.2 GCC implements the resolution to DR 233, so
	that insertions happen as close as possible to the hint. For
	earlier releases the hint was only used as described below.
	</p><p>
	Here we'll describe how the hinting works in the libstdc++
	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 <span class="emphasis"><em>greater
	than</em></span> and <span class="emphasis"><em>less than</em></span> refer to the
	results of the strict weak ordering imposed on the container by
	its comparison object, which defaults to (basically)
	<span class="quote">“<span class="quote"><</span>”</span>. 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 <span class="quote">“<span class="quote">greater</span>”</span>
	and <span class="quote">“<span class="quote">lesser</span>”</span> their new meanings in the next
	paragraph. grin
	</p><p>
	If the <code class="code">hint</code> parameter ('p' above) is equivalent to:
	</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
	<code class="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 class="code">begin()</code>.
	</p></li><li class="listitem"><p>
	<code class="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 before <code class="code">end()</code>.
	</p></li><li class="listitem"><p>
	neither <code class="code">begin()</code> nor <code class="code">end()</code>, then:
	Let <code class="code">h</code> be the entry in the container pointed to
	by <code class="code">hint</code>, that is, <code class="code">h = *hint</code>. Then
	the item being inserted should have a key less than that of
	<code class="code">h</code>, and greater than that of the item preceding
	<code class="code">h</code>. The new item will be inserted between
	<code class="code">h</code> and <code class="code">h</code>'s predecessor.
	</p></li></ul></div><p>
	For <code class="code">multimap</code> and <code class="code">multiset</code>, the
	restrictions are slightly looser: <span class="quote">“<span class="quote">greater than</span>”</span>
	should be replaced by <span class="quote">“<span class="quote">not less than</span>”</span>and <span class="quote">“<span class="quote">less
	than</span>”</span> should be replaced by <span class="quote">“<span class="quote">not greater
	than.</span>”</span> (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 class="code"> a.insert(t)
	</code> instead. (<span class="emphasis"><em>Note </em></span> that GCC releases
	prior to 3.0.2 had a bug in the case with <code class="code">hint ==
	begin()</code> for the <code class="code">map</code> and <code class="code">set</code>
	classes. You should not use a hint argument in those releases.)
	</p><p>
	This behavior goes well with other containers'
	<code class="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.
	</p><p>
	<span class="emphasis"><em>Note </em></span> also that the hint in this
	implementation is a one-shot. The older 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.
	</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="containers.associative.bitset"></a>bitset</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="associative.bitset.size_variable"></a>Size Variable</h4></div></div></div><p>
	No, you cannot write code of the form
	</p><pre class="programlisting">
	#include <bitset>

	void foo (size_t n)
	{
	std::bitset<n> bits;
	....
	}
	</pre><p>
	because <code class="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 <span class="emphasis"><em>is</em></span> 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:
	</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>A very large N in <code class="code">bitset<N></code>.</p></li><li class="listitem"><p>A container<bool>.</p></li><li class="listitem"><p>Extremely weird solutions.</p></li></ul></div><p>
	<span class="emphasis"><em>A very large N in
	<code class="code">bitset<N></code>. </em></span> 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.,
	<span class="quote">“<span class="quote">changed</span>”</span>/<span class="quote">“<span class="quote">unchanged</span>”</span> flags), that's a
	<span class="emphasis"><em>lot</em></span> of state.
	</p><p>
	You can then keep track of the <span class="quote">“<span class="quote">maximum bit used</span>”</span>
	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>
	<span class="emphasis"><em>A container<bool>. </em></span> 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 class="code">Container<char></code> or
	<code class="code">Container<short int></code>. Specifically,
	<code class="code">vector<bool></code> is required to be specialized for
	that space savings.
	</p><p>
	The problem is that <code class="code">vector<bool></code> doesn't
	behave like a normal vector anymore. There have been
	journal articles which discuss the problems (the ones by Herb
	Sutter in the May and July/August 1999 issues of C++ Report cover
	it well). Future revisions of the ISO C++ Standard will change
	the requirement for <code class="code">vector<bool></code>
	specialization. In the meantime, <code class="code">deque<bool></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>
	<span class="emphasis"><em>Extremely weird solutions. </em></span> 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 class="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 Independent Code, then open the newly-created object
	file and load those wrapper functions. You'll have an
	instantiation of <code class="code">bitset<N></code> for the exact
	<code class="code">N</code> that you need at the time. Don't forget to delete
	the temporary files. (Yes, this <span class="emphasis"><em>can</em></span> be, and
	<span class="emphasis"><em>has been</em></span>, done.)
	</p><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++ has
	<a class="link" href="ext_containers.html#manual.ext.containers.sgi" title="Backwards Compatibility">some extensions</a>.
	</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="associative.bitset.type_string"></a>Type String</h4></div></div></div><p>
	</p><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 <span class="quote">“<span class="quote">Links</span>”</span> from
	the homepage, and from the C++ information <span class="quote">“<span class="quote">defect
	reflector</span>”</span> 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:
	</p><pre class="programlisting">
	std::bitset<5> b ( std::string("10110") );
	</pre><p>
	instead of
	</p><pre class="programlisting">
	std::bitset<5> b ( "10110" ); // invalid
	</pre></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="containers.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="containers.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="unordered_associative.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 9.
	Containers

	</td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Unordered Associative</td></tr></table></div></body></html>