sumofight I like std::vector a lot. I use it almost everytime I need a container. I like it because it is very simple to use, it is very efficient (the data is stored contiguously in memory). It is even good for insertion of new elements: if one knows in advance the number of elements, the insertion cost (at the end) is O(1), just like std::list, and it is O(log(n)) when one uses push_back (it does not reallocate each time a new element is appended). When the number of elements is small (let's say less than 30), searching for a value is generally faster with an (unsorted) std::vector than with something more powerful such as std::set.

std::vector is a good general purpose solution.

So I use it a lot. On a lot of classes. And I came to wonder what is the impact of using all these std::vector<...> on the code size. Is it more "dense" than other containers, such as std::list ?

As an experiment, I took a small program instanciating 100 container classes std::vector<FooPlop1>, std::vector<FooPlop2>, ....std::vector<FooPlop100> . The program creates the containers, fill them once, and iterates on them (with a simple side-effect so that the compiler is not tempted to optimize everything away). Here are the results for various gcc versions / optimizations flags, the first column give the size in byte of each std::vector<FooPlopXX> (that is the total stripped binary size divided by 100), the second one gives the compilation time (in seconds). The compiler used is g++-4.3 on debian, but the relative results do not seem to depend too much on the compiler version (I checked with gcc 3.4, 4.1, 4.2, and version 4.3 was the best). Building 64bit binaries has no more effect than a general 20-30% increase in size.

# std::vector
 3058 16.98 # g++-4.3 -m32
  697 17.61 # g++-4.3 -m32 -O2
 1319 27.20 # g++-4.3 -m32 -O3
  599 15.79 # g++-4.3 -m32 -Os
# std::list
 1708 11.66 # g++-4.3 -m32
  293  9.76 # g++-4.3 -m32 -O2
  575 26.17 # g++-4.3 -m32 -O3
  288  9.16 # g++-4.3 -m32 -Os
# __gnu_cxx::slist
 1845 12.01 # g++-4.3 -m32
  467 10.86 # g++-4.3 -m32 -O2
  848 17.28 # g++-4.3 -m32 -O3
  413  9.97 # g++-4.3 -m32 -Os
# std::deque
 8219 39.19 # g++-4.3 -m32
 3407 55.98 # g++-4.3 -m32 -O2
 3442 59.47 # g++-4.3 -m32 -O3
 2751 44.31 # g++-4.3 -m32 -Os
# std::set
 4703 26.32 # g++-4.3 -m32
  864 18.36 # g++-4.3 -m32 -O2
 1306 22.22 # g++-4.3 -m32 -O3
  774 17.68 # g++-4.3 -m32 -Os

So what are the conclusions ? std::list wins easily against all others containers on the "bloat" side (we can ignore slist which is deprecated). And it compiles much quicker.

However, std::set is much, much less bloated than what I imagined, good to know.

std::deque proves once again that he is the shame of the STL containers. Slow to compile (50 seconds for a program that just instantiates 100 different std::deque is a lot!) , slow to iterate, AND bloated.

A last remark: using containers of pointers (std::vector<FooPlop1*>) does not change the numbers given above.