Chapter 23 deals with container classes and what they offer.
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.
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 "container" on which they work, since the algorithms are only given endpoints to work with. For the container classes, these are iterators (usually begin() and end(), but not always). For builtin arrays, these are the address of the first element and the past-the-end element.
Some very simple wrapper functions can hide all of that from the rest of the code. For example, a pair of functions called beginof 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 begin() iterator.
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 beginof being optimized out of existence, so you pay absolutely nothing in terms of increased code size or execution time.
The result is that if all your algorithm calls look like
std::transform(beginof(foo), endof(foo), beginof(foo), SomeFunction);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.
This author has a collection of such functions, called "*of" because they all extend the builtin "sizeof". 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 given here.
Astute readers will notice two things at once: first, that the container class is still a vector<T> instead of a more general Container<T>. This would mean that three functions for deque would have to be added, another three for list, 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.
Second, the line
inline unsigned int lengthof (T (&)[sz]) { return sz; }
looks just weird! Hint: unused parameters can be left nameless.
Return to top of page or to the FAQ.
No, you cannot write code of the form
#include <bitset>
void foo (size_t n)
{
std::bitset<n> bits;
....
}
because n must be known at compile time. Your compiler is
correct; it is not a bug. That's the way templates work. (Yes, it
is a feature.)
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:
A very large N in bitset<N>. 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., "changed"/"unchanged" flags), that's a lot of state.
You can then keep track of the "maximum bit used" 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.)
A container<bool>. 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 Container<char> or Container<short int>. Specifically, vector<bool> is required to be specialized for that space savings.
The problem is that vector<bool> 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 C++ Report cover it well). Future revisions of the ISO C++ Standard will change the requirement for vector<bool> specialization. In the meantime, deque<bool> 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).
Extremely weird solutions. 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 bitset 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 bitset<N> for the exact N that you need at the time. Don't forget to delete the temporary files. (Yes, this can be, and has been, done.)
This would be the approach of either a visionary genius or a raving lunatic, depending on your programming and management style. Probably the latter.
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...
Return to top of page or to the FAQ.
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.
Two excellent pages to read when working with templatized containers and threads are SGI's http://www.sgi.com/tech/stl/thread_safety.html and SGI's http://www.sgi.com/tech/stl/Allocators.html. 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 ("For most clients,"...), pointing out that locking must nearly always be done outside the container, by client code (that'd be you, not us *grin*). 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 may or may not be 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.
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).
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 string, 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.
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 to a certain extent, 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.
Return to top of page or to the FAQ.
Comments and suggestions are welcome, and may be sent to
the mailing list.
$Id: howto.html,v 1.4 2001/05/30 21:55:01 pme Exp $