OSDN Git Service

* include/bits/c++config (__USE_MALLOC): Do not define it.
[pf3gnuchains/gcc-fork.git] / libstdc++-v3 / docs / html / 23_containers / howto.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
2 <HTML>
3 <HEAD>
4    <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
5    <META NAME="AUTHOR" CONTENT="pme@sources.redhat.com (Phil Edwards)">
6    <META NAME="KEYWORDS" CONTENT="HOWTO, libstdc++, GCC, g++, libg++, STL">
7    <META NAME="DESCRIPTION" CONTENT="HOWTO for the libstdc++ chapter 23.">
8    <META NAME="GENERATOR" CONTENT="vi and eight fingers">
9    <TITLE>libstdc++-v3 HOWTO:  Chapter 23</TITLE>
10 <LINK REL=StyleSheet HREF="../lib3styles.css">
11 <!-- $Id: howto.html,v 1.4 2001/05/30 21:55:01 pme Exp $ -->
12 </HEAD>
13 <BODY>
14
15 <H1 CLASS="centered"><A NAME="top">Chapter 23:  Containers</A></H1>
16
17 <P>Chapter 23 deals with container classes and what they offer.
18 </P>
19
20
21 <!-- ####################################################### -->
22 <HR>
23 <H1>Contents</H1>
24 <UL>
25    <LI><A HREF="#1">Making code unaware of the container/array difference</A>
26    <LI><A HREF="#2">Variable-sized bitmasks</A>
27    <LI><A HREF="#3">Containers and multithreading</A>
28 </UL>
29
30 <HR>
31
32 <!-- ####################################################### -->
33
34 <H2><A NAME="1">Making code unaware of the container/array difference</A></H2>
35    <P>You're writing some code and can't decide whether to use builtin
36       arrays or some kind of container.  There are compelling reasons 
37       to use one of the container classes, but you're afraid that you'll
38       eventually run into difficulties, change everything back to arrays,
39       and then have to change all the code that uses those data types to
40       keep up with the change.
41    </P>
42    <P>If your code makes use of the standard algorithms, this isn't as
43       scary as it sounds.  The algorithms don't know, nor care, about
44       the kind of &quot;container&quot; on which they work, since the
45       algorithms are only given endpoints to work with.  For the container
46       classes, these are iterators (usually <TT>begin()</TT> and
47       <TT>end()</TT>, but not always).  For builtin arrays, these are
48       the address of the first element and the
49       <A HREF="../24_iterators/howto.html#2">past-the-end</A> element.
50    </P>
51    <P>Some very simple wrapper functions can hide all of that from the
52       rest of the code.  For example, a pair of functions called
53       <TT>beginof</TT> can be written, one that takes an array, another
54       that takes a vector.  The first returns a pointer to the first
55       element, and the second returns the vector's <TT>begin()</TT>
56       iterator.
57    </P>
58    <P>The functions should be made template functions, and should also 
59       be declared inline.  As pointed out in the comments in the code 
60       below, this can lead to <TT>beginof</TT> being optimized out of
61       existence, so you pay absolutely nothing in terms of increased
62       code size or execution time.
63    </P>
64    <P>The result is that if all your algorithm calls look like
65       <PRE>
66    std::transform(beginof(foo), endof(foo), beginof(foo), SomeFunction);</PRE>
67       then the type of foo can change from an array of ints to a vector
68       of ints to a deque of ints and back again, without ever changing any
69       client code.
70    </P>
71    <P>This author has a collection of such functions, called &quot;*of&quot;
72       because they all extend the builtin &quot;sizeof&quot;.  It started
73       with some Usenet discussions on a transparent way to find the length
74       of an array.  A simplified and much-reduced version for easier
75       reading is <A HREF="wrappers_h.txt">given here</A>.
76    </P>
77    <P>Astute readers will notice two things at once:  first, that the
78       container class is still a <TT>vector&lt;T&gt;</TT> instead of a
79       more general <TT>Container&lt;T&gt;</TT>.  This would mean that
80       three functions for <TT>deque</TT> would have to be added, another
81       three for <TT>list</TT>, and so on.  This is due to problems with
82       getting template resolution correct; I find it easier just to 
83       give the extra three lines and avoid confusion.
84    </P>
85    <P>Second, the line
86       <PRE>
87     inline unsigned int lengthof (T (&amp;)[sz]) { return sz; } </PRE>
88       looks just weird!  Hint:  unused parameters can be left nameless.
89    </P>
90    <P>Return <A HREF="#top">to top of page</A> or
91       <A HREF="../faq/index.html">to the FAQ</A>.
92    </P>
93
94 <HR>
95 <H2><A NAME="2">Variable-sized bitmasks</A></H2>
96    <P>No, you cannot write code of the form
97       <!-- Careful, the leading spaces in PRE show up directly. -->
98       <PRE>
99       #include &lt;bitset&gt;
100
101       void foo (size_t n)
102       {
103           std::bitset&lt;n&gt;   bits;
104           ....
105       } </PRE>
106       because <TT>n</TT> must be known at compile time.  Your compiler is
107       correct; it is not a bug.  That's the way templates work.  (Yes, it
108       <EM>is</EM> a feature.)
109    </P>
110    <P>There are a couple of ways to handle this kind of thing.  Please
111       consider all of them before passing judgement.  They include, in
112       no particular order:
113       <UL>
114         <LI>A very large N in <TT>bitset&lt;N&gt;</TT>.
115         <LI>A container&lt;bool&gt;.
116         <LI>Extremely weird solutions.
117       </UL>
118    </P>
119    <P><B>A very large N in <TT>bitset&lt;N&gt;</TT>.&nbsp;&nbsp;</B>  It has
120       been pointed out a few times in newsgroups that N bits only takes up
121       (N/8) bytes on most systems, and division by a factor of eight is pretty
122       impressive when speaking of memory.  Half a megabyte given over to a
123       bitset (recall that there is zero space overhead for housekeeping info;
124       it is known at compile time exactly how large the set is) will hold over
125       four million bits.  If you're using those bits as status flags (e.g.,
126       &quot;changed&quot;/&quot;unchanged&quot; flags), that's a <EM>lot</EM>
127       of state.
128    </P>
129    <P>You can then keep track of the &quot;maximum bit used&quot; during some
130       testing runs on representative data, make note of how many of those bits
131       really need to be there, and then reduce N to a smaller number.  Leave
132       some extra space, of course.  (If you plan to write code like the 
133       incorrect example above, where the bitset is a local variable, then you
134       may have to talk your compiler into allowing that much stack space;
135       there may be zero space overhead, but it's all allocated inside the
136       object.)
137    </P>
138    <P><B>A container&lt;bool&gt;.&nbsp;&nbsp;</B>  The Committee made provision
139       for the space savings possible with that (N/8) usage previously mentioned,
140       so that you don't have to do wasteful things like
141       <TT>Container&lt;char&gt;</TT> or <TT>Container&lt;short int&gt;</TT>.
142       Specifically, <TT>vector&lt;bool&gt;</TT> is required to be
143       specialized for that space savings.
144    </P>
145    <P>The problem is that <TT>vector&lt;bool&gt;</TT> doesn't behave like a
146       normal vector anymore.  There have been recent journal articles which
147       discuss the problems (the ones by Herb Sutter in the May and
148       July/August 1999 issues of
149       <EM>C++ Report</EM> cover it well).  Future revisions of the ISO C++
150       Standard will change the requirement for <TT>vector&lt;bool&gt;</TT>
151       specialization.  In the meantime, <TT>deque&lt;bool&gt;</TT> is
152       recommended (although its behavior is sane, you probably will not get
153       the space savings, but the allocation scheme is different than that
154       of vector).
155    </P>
156    <P><B>Extremely weird solutions.&nbsp;&nbsp;</B>  If you have access to
157       the compiler and linker at runtime, you can do something insane, like
158       figuring out just how many bits you need, then writing a temporary 
159       source code file.  That file contains an instantiation of <TT>bitset</TT>
160       for the required number of bits, inside some wrapper functions with
161       unchanging signatures.  Have your program then call the
162       compiler on that file using Position Independant Code, then open the
163       newly-created object file and load those wrapper functions.  You'll have
164       an instantiation of <TT>bitset&lt;N&gt;</TT> for the exact <TT>N</TT>
165       that you need at the time.  Don't forget to delete the temporary files.
166       (Yes, this <EM>can</EM> be, and <EM>has been</EM>, done.)
167    </P>
168    <!-- I wonder if this next paragraph will get me in trouble... -->
169    <P>This would be the approach of either a visionary genius or a raving
170       lunatic, depending on your programming and management style.  Probably
171       the latter.
172    </P>
173    <P>Which of the above techniques you use, if any, are up to you and your
174       intended application.  Some time/space profiling is indicated if it
175       really matters (don't just guess).  And, if you manage to do anything
176       along the lines of the third category, the author would love to hear
177       from you...
178    </P>
179    <P>Return <A HREF="#top">to top of page</A> or
180       <A HREF="../faq/index.html">to the FAQ</A>.
181    </P>
182
183 <HR>
184 <H2><A NAME="3">Containers and multithreading</A></H2>
185    <P>This section will mention some of the problems in designing MT
186       programs that use Standard containers.  For information on other
187       aspects of multithreading (e.g., the library as a whole), see
188       the Received Wisdom on Chapter 17.
189    </P>
190    <P>Two excellent pages to read when working with templatized containers
191       and threads are
192       <A HREF="http://www.sgi.com/tech/stl/thread_safety.html">SGI's
193       http://www.sgi.com/tech/stl/thread_safety.html</A> and
194       <A HREF="http://www.sgi.com/tech/stl/Allocators.html">SGI's
195       http://www.sgi.com/tech/stl/Allocators.html</A>.  The
196       libstdc++-v3 uses the same definition of thread safety
197       when discussing design.  A key point that beginners may miss is the
198       fourth major paragraph of the first page mentioned above
199       (&quot;For most clients,&quot;...), pointing
200       out that locking must nearly always be done outside the container,
201       by client code (that'd be you, not us *grin*).
202       <EM>However, please take caution when considering the discussion
203       about the user-level configuration of the mutex lock
204       implementation inside the STL container-memory allocator on that
205       page.  For the sake of this discussion, libstdc++-v3 configures
206       the SGI STL implementation, not you.  We attempt to configure
207       the mutex lock as is best for your platform.  In particular,
208       past advice was for people using g++ to explicitly define
209       _PTHREADS on the command line to get a thread-safe STL.  This
210       may or may not be required for your port.  It may or may not be
211       a good idea for your port.  Extremely big caution: if you
212       compile some of your application code against the STL with one
213       set of threading flags and macros and another portion of the
214       code with different flags and macros that influence the
215       selection of the mutex lock, you may well end up with multiple
216       locking mechanisms in use which don't impact each other in the
217       manner that they should.  Everything might link and all code
218       might have been built with a perfectly reasonable thread model
219       but you may have two internal ABIs in play within the
220       application.  This might produce races, memory leaks and fatal
221       crashes.  In any multithreaded application using STL, this
222       is the first thing to study well before blaming the allocator.</EM>
223    </P>
224    <P>You didn't read it, did you?  *sigh*  I'm serious, go read the
225       SGI page.  It's really good and doesn't take long, and makes most
226       of the points that would otherwise have to be made here (and does
227       a better job).
228    </P>
229    <P>That's much better.  Now, the issue of MT has been brought up on
230       the libstdc++-v3 mailing list as well as the main GCC mailing list
231       several times.  The Chapter 17 HOWTO has some links into the mail
232       archives, so you can see what's been thrown around.  The usual
233       container (or pseudo-container, depending on how you look at it)
234       that people have in mind is <TT>string</TT>, which is one of the
235       points where libstdc++ departs from the SGI STL.  As of the
236       2.90.8 snapshot, the libstdc++-v3 string class is safe for
237       certain kinds of multithreaded access.
238    </P>
239    <P>For implementing a container which does its own locking, it is
240       trivial to (as SGI suggests) provide a wrapper class which obtains
241       the lock, performs the container operation, then releases the lock.
242       This could be templatized <EM>to a certain extent</EM>, on the
243       underlying container and/or a locking mechanism.  Trying to provide
244       a catch-all general template solution would probably be more trouble
245       than it's worth.
246    </P>
247
248    <P>Return <A HREF="#top">to top of page</A> or
249       <A HREF="../faq/index.html">to the FAQ</A>.
250    </P>
251
252
253
254
255 <!-- ####################################################### -->
256
257 <HR>
258 <P CLASS="fineprint"><EM>
259 Comments and suggestions are welcome, and may be sent to
260 <A HREF="mailto:libstdc++@gcc.gnu.org">the mailing list</A>.
261 <BR> $Id: howto.html,v 1.4 2001/05/30 21:55:01 pme Exp $
262 </EM></P>
263
264
265 </BODY>
266 </HTML>