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