1*36ac495dSmrg<?xml version="1.0" encoding="UTF-8" standalone="no"?> 2*36ac495dSmrg<!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. 3*36ac495dSmrg Containers 4*36ac495dSmrg 5*36ac495dSmrg</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> 6*36ac495dSmrg Section [23.1.2], Table 69, of the C++ standard lists this 7*36ac495dSmrg function for all of the associative containers (map, set, etc): 8*36ac495dSmrg </p><pre class="programlisting"> 9*36ac495dSmrg a.insert(p,t); 10*36ac495dSmrg </pre><p> 11*36ac495dSmrg where 'p' is an iterator into the container 'a', and 't' is the 12*36ac495dSmrg item to insert. The standard says that <span class="quote">“<span class="quote"><code class="code">t</code> is 13*36ac495dSmrg inserted as close as possible to the position just prior to 14*36ac495dSmrg <code class="code">p</code>.</span>”</span> (Library DR #233 addresses this topic, 15*36ac495dSmrg referring to <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html" target="_top">N1780</a>. 16*36ac495dSmrg Since version 4.2 GCC implements the resolution to DR 233, so 17*36ac495dSmrg that insertions happen as close as possible to the hint. For 18*36ac495dSmrg earlier releases the hint was only used as described below. 19*36ac495dSmrg </p><p> 20*36ac495dSmrg Here we'll describe how the hinting works in the libstdc++ 21*36ac495dSmrg implementation, and what you need to do in order to take 22*36ac495dSmrg advantage of it. (Insertions can change from logarithmic 23*36ac495dSmrg complexity to amortized constant time, if the hint is properly 24*36ac495dSmrg used.) Also, since the current implementation is based on the 25*36ac495dSmrg SGI STL one, these points may hold true for other library 26*36ac495dSmrg implementations also, since the HP/SGI code is used in a lot of 27*36ac495dSmrg places. 28*36ac495dSmrg </p><p> 29*36ac495dSmrg In the following text, the phrases <span class="emphasis"><em>greater 30*36ac495dSmrg than</em></span> and <span class="emphasis"><em>less than</em></span> refer to the 31*36ac495dSmrg results of the strict weak ordering imposed on the container by 32*36ac495dSmrg its comparison object, which defaults to (basically) 33*36ac495dSmrg <span class="quote">“<span class="quote"><</span>”</span>. Using those phrases is semantically sloppy, 34*36ac495dSmrg but I didn't want to get bogged down in syntax. I assume that if 35*36ac495dSmrg you are intelligent enough to use your own comparison objects, 36*36ac495dSmrg you are also intelligent enough to assign <span class="quote">“<span class="quote">greater</span>”</span> 37*36ac495dSmrg and <span class="quote">“<span class="quote">lesser</span>”</span> their new meanings in the next 38*36ac495dSmrg paragraph. *grin* 39*36ac495dSmrg </p><p> 40*36ac495dSmrg If the <code class="code">hint</code> parameter ('p' above) is equivalent to: 41*36ac495dSmrg </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p> 42*36ac495dSmrg <code class="code">begin()</code>, then the item being inserted should 43*36ac495dSmrg have a key less than all the other keys in the container. 44*36ac495dSmrg The item will be inserted at the beginning of the container, 45*36ac495dSmrg becoming the new entry at <code class="code">begin()</code>. 46*36ac495dSmrg </p></li><li class="listitem"><p> 47*36ac495dSmrg <code class="code">end()</code>, then the item being inserted should have 48*36ac495dSmrg a key greater than all the other keys in the container. The 49*36ac495dSmrg item will be inserted at the end of the container, becoming 50*36ac495dSmrg the new entry before <code class="code">end()</code>. 51*36ac495dSmrg </p></li><li class="listitem"><p> 52*36ac495dSmrg neither <code class="code">begin()</code> nor <code class="code">end()</code>, then: 53*36ac495dSmrg Let <code class="code">h</code> be the entry in the container pointed to 54*36ac495dSmrg by <code class="code">hint</code>, that is, <code class="code">h = *hint</code>. Then 55*36ac495dSmrg the item being inserted should have a key less than that of 56*36ac495dSmrg <code class="code">h</code>, and greater than that of the item preceding 57*36ac495dSmrg <code class="code">h</code>. The new item will be inserted between 58*36ac495dSmrg <code class="code">h</code> and <code class="code">h</code>'s predecessor. 59*36ac495dSmrg </p></li></ul></div><p> 60*36ac495dSmrg For <code class="code">multimap</code> and <code class="code">multiset</code>, the 61*36ac495dSmrg restrictions are slightly looser: <span class="quote">“<span class="quote">greater than</span>”</span> 62*36ac495dSmrg should be replaced by <span class="quote">“<span class="quote">not less than</span>”</span>and <span class="quote">“<span class="quote">less 63*36ac495dSmrg than</span>”</span> should be replaced by <span class="quote">“<span class="quote">not greater 64*36ac495dSmrg than.</span>”</span> (Why not replace greater with 65*36ac495dSmrg greater-than-or-equal-to? You probably could in your head, but 66*36ac495dSmrg the mathematicians will tell you that it isn't the same thing.) 67*36ac495dSmrg </p><p> 68*36ac495dSmrg If the conditions are not met, then the hint is not used, and the 69*36ac495dSmrg insertion proceeds as if you had called <code class="code"> a.insert(t) 70*36ac495dSmrg </code> instead. (<span class="emphasis"><em>Note </em></span> that GCC releases 71*36ac495dSmrg prior to 3.0.2 had a bug in the case with <code class="code">hint == 72*36ac495dSmrg begin()</code> for the <code class="code">map</code> and <code class="code">set</code> 73*36ac495dSmrg classes. You should not use a hint argument in those releases.) 74*36ac495dSmrg </p><p> 75*36ac495dSmrg This behavior goes well with other containers' 76*36ac495dSmrg <code class="code">insert()</code> functions which take an iterator: if used, 77*36ac495dSmrg the new item will be inserted before the iterator passed as an 78*36ac495dSmrg argument, same as the other containers. 79*36ac495dSmrg </p><p> 80*36ac495dSmrg <span class="emphasis"><em>Note </em></span> also that the hint in this 81*36ac495dSmrg implementation is a one-shot. The older insertion-with-hint 82*36ac495dSmrg routines check the immediately surrounding entries to ensure that 83*36ac495dSmrg the new item would in fact belong there. If the hint does not 84*36ac495dSmrg point to the correct place, then no further local searching is 85*36ac495dSmrg done; the search begins from scratch in logarithmic time. 86*36ac495dSmrg </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> 87*36ac495dSmrg No, you cannot write code of the form 88*36ac495dSmrg </p><pre class="programlisting"> 89*36ac495dSmrg #include <bitset> 90*36ac495dSmrg 91*36ac495dSmrg void foo (size_t n) 92*36ac495dSmrg { 93*36ac495dSmrg std::bitset<n> bits; 94*36ac495dSmrg .... 95*36ac495dSmrg } 96*36ac495dSmrg </pre><p> 97*36ac495dSmrg because <code class="code">n</code> must be known at compile time. Your 98*36ac495dSmrg compiler is correct; it is not a bug. That's the way templates 99*36ac495dSmrg work. (Yes, it <span class="emphasis"><em>is</em></span> a feature.) 100*36ac495dSmrg </p><p> 101*36ac495dSmrg There are a couple of ways to handle this kind of thing. Please 102*36ac495dSmrg consider all of them before passing judgement. They include, in 103*36ac495dSmrg no particular order: 104*36ac495dSmrg </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> 105*36ac495dSmrg <span class="emphasis"><em>A very large N in 106*36ac495dSmrg <code class="code">bitset<N></code>. </em></span> It has been 107*36ac495dSmrg pointed out a few times in newsgroups that N bits only takes up 108*36ac495dSmrg (N/8) bytes on most systems, and division by a factor of eight is 109*36ac495dSmrg pretty impressive when speaking of memory. Half a megabyte given 110*36ac495dSmrg over to a bitset (recall that there is zero space overhead for 111*36ac495dSmrg housekeeping info; it is known at compile time exactly how large 112*36ac495dSmrg the set is) will hold over four million bits. If you're using 113*36ac495dSmrg those bits as status flags (e.g., 114*36ac495dSmrg <span class="quote">“<span class="quote">changed</span>”</span>/<span class="quote">“<span class="quote">unchanged</span>”</span> flags), that's a 115*36ac495dSmrg <span class="emphasis"><em>lot</em></span> of state. 116*36ac495dSmrg </p><p> 117*36ac495dSmrg You can then keep track of the <span class="quote">“<span class="quote">maximum bit used</span>”</span> 118*36ac495dSmrg during some testing runs on representative data, make note of how 119*36ac495dSmrg many of those bits really need to be there, and then reduce N to 120*36ac495dSmrg a smaller number. Leave some extra space, of course. (If you 121*36ac495dSmrg plan to write code like the incorrect example above, where the 122*36ac495dSmrg bitset is a local variable, then you may have to talk your 123*36ac495dSmrg compiler into allowing that much stack space; there may be zero 124*36ac495dSmrg space overhead, but it's all allocated inside the object.) 125*36ac495dSmrg </p><p> 126*36ac495dSmrg <span class="emphasis"><em>A container<bool>. </em></span> The 127*36ac495dSmrg Committee made provision for the space savings possible with that 128*36ac495dSmrg (N/8) usage previously mentioned, so that you don't have to do 129*36ac495dSmrg wasteful things like <code class="code">Container<char></code> or 130*36ac495dSmrg <code class="code">Container<short int></code>. Specifically, 131*36ac495dSmrg <code class="code">vector<bool></code> is required to be specialized for 132*36ac495dSmrg that space savings. 133*36ac495dSmrg </p><p> 134*36ac495dSmrg The problem is that <code class="code">vector<bool></code> doesn't 135*36ac495dSmrg behave like a normal vector anymore. There have been 136*36ac495dSmrg journal articles which discuss the problems (the ones by Herb 137*36ac495dSmrg Sutter in the May and July/August 1999 issues of C++ Report cover 138*36ac495dSmrg it well). Future revisions of the ISO C++ Standard will change 139*36ac495dSmrg the requirement for <code class="code">vector<bool></code> 140*36ac495dSmrg specialization. In the meantime, <code class="code">deque<bool></code> 141*36ac495dSmrg is recommended (although its behavior is sane, you probably will 142*36ac495dSmrg not get the space savings, but the allocation scheme is different 143*36ac495dSmrg than that of vector). 144*36ac495dSmrg </p><p> 145*36ac495dSmrg <span class="emphasis"><em>Extremely weird solutions. </em></span> If 146*36ac495dSmrg you have access to the compiler and linker at runtime, you can do 147*36ac495dSmrg something insane, like figuring out just how many bits you need, 148*36ac495dSmrg then writing a temporary source code file. That file contains an 149*36ac495dSmrg instantiation of <code class="code">bitset</code> for the required number of 150*36ac495dSmrg bits, inside some wrapper functions with unchanging signatures. 151*36ac495dSmrg Have your program then call the compiler on that file using 152*36ac495dSmrg Position Independent Code, then open the newly-created object 153*36ac495dSmrg file and load those wrapper functions. You'll have an 154*36ac495dSmrg instantiation of <code class="code">bitset<N></code> for the exact 155*36ac495dSmrg <code class="code">N</code> that you need at the time. Don't forget to delete 156*36ac495dSmrg the temporary files. (Yes, this <span class="emphasis"><em>can</em></span> be, and 157*36ac495dSmrg <span class="emphasis"><em>has been</em></span>, done.) 158*36ac495dSmrg </p><p> 159*36ac495dSmrg This would be the approach of either a visionary genius or a 160*36ac495dSmrg raving lunatic, depending on your programming and management 161*36ac495dSmrg style. Probably the latter. 162*36ac495dSmrg </p><p> 163*36ac495dSmrg Which of the above techniques you use, if any, are up to you and 164*36ac495dSmrg your intended application. Some time/space profiling is 165*36ac495dSmrg indicated if it really matters (don't just guess). And, if you 166*36ac495dSmrg manage to do anything along the lines of the third category, the 167*36ac495dSmrg author would love to hear from you... 168*36ac495dSmrg </p><p> 169*36ac495dSmrg Also note that the implementation of bitset used in libstdc++ has 170*36ac495dSmrg <a class="link" href="ext_containers.html#manual.ext.containers.sgi" title="Backwards Compatibility">some extensions</a>. 171*36ac495dSmrg </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> 172*36ac495dSmrg </p><p> 173*36ac495dSmrg Bitmasks do not take char* nor const char* arguments in their 174*36ac495dSmrg constructors. This is something of an accident, but you can read 175*36ac495dSmrg about the problem: follow the library's <span class="quote">“<span class="quote">Links</span>”</span> from 176*36ac495dSmrg the homepage, and from the C++ information <span class="quote">“<span class="quote">defect 177*36ac495dSmrg reflector</span>”</span> link, select the library issues list. Issue 178*36ac495dSmrg number 116 describes the problem. 179*36ac495dSmrg </p><p> 180*36ac495dSmrg For now you can simply make a temporary string object using the 181*36ac495dSmrg constructor expression: 182*36ac495dSmrg </p><pre class="programlisting"> 183*36ac495dSmrg std::bitset<5> b ( std::string("10110") ); 184*36ac495dSmrg </pre><p> 185*36ac495dSmrg instead of 186*36ac495dSmrg </p><pre class="programlisting"> 187*36ac495dSmrg std::bitset<5> b ( "10110" ); // invalid 188*36ac495dSmrg </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. 189*36ac495dSmrg Containers 190*36ac495dSmrg 191*36ac495dSmrg </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>