# Containers

Containers
ISO C++ library

## Sequences

### list

#### list::size() is O(n)

Yes it is, and that was okay until the 2011 edition of the C++ standard. In future GCC will change it to O(1) but O(N) was a decision that we preserved when we imported SGI's STL implementation. The following is quoted from their FAQ:

> The size() member function, for list and slist, takes time proportional to the number of elements in the list. This was a deliberate tradeoff. The only way to get a constant-time size() for linked lists would be to maintain an extra member variable containing the list's size. This would require taking extra time to update that variable (it would make splice() a linear time operation, for example), and it would also make the list larger. Many list algorithms don't require that extra word (algorithms that do require it might do better with vectors than with lists), and, when it is necessary to maintain an explicit size count, it's something that users can do themselves.

> This choice is permitted by the C++ standard. The standard says that size() should be constant time, and should does not mean the same thing as shall. This is the officially recommended ISO wording for saying that an implementation is supposed to do something unless there is a good reason not to.

> One implication of linear time size(): you should never write

>     	 if (L.size() == 0)
>     	     ...

> Instead, you should write

>     	 if (L.empty())
>     	     ...

## Associative

### Insertion Hints

Section [23.1.2], Table 69, of the C++ standard lists this function for all of the associative containers (map, set, etc):

          a.insert(p,t);

where 'p' is an iterator into the container 'a', and 't' is the item to insert. The standard says that `t` is inserted as close as possible to the position just prior to `p`. (Library DR #233 addresses this topic, referring to N1780. Since version 4.2 GCC implements the resolution to DR 233, so that insertions happen as close as possible to the hint. For earlier releases the hint was only used as described below.

Here we'll describe how the hinting works in the libstdc++ implementation, and what you need to do in order to take advantage of it. (Insertions can change from logarithmic complexity to amortized constant time, if the hint is properly used.) Also, since the current implementation is based on the SGI STL one, these points may hold true for other library implementations also, since the HP/SGI code is used in a lot of places.

In the following text, the phrases greater than and less than refer to the results of the strict weak ordering imposed on the container by its comparison object, which defaults to (basically) <. Using those phrases is semantically sloppy, but I didn't want to get bogged down in syntax. I assume that if you are intelligent enough to use your own comparison objects, you are also intelligent enough to assign greater and lesser their new meanings in the next paragraph. *grin*

If the `hint` parameter ('p' above) is equivalent to:

- `begin()`, then the item being inserted should have a key less than all the other keys in the container. The item will be inserted at the beginning of the container, becoming the new entry at `begin()`.

- `end()`, then the item being inserted should have a key greater than all the other keys in the container. The item will be inserted at the end of the container, becoming the new entry before `end()`.

- neither `begin()` nor `end()`, then: Let `h` be the entry in the container pointed to by `hint`, that is, `h = *hint`. Then the item being inserted should have a key less than that of `h`, and greater than that of the item preceding `h`. The new item will be inserted between `h` and `h`'s predecessor.

For `multimap` and `multiset`, the restrictions are slightly looser: greater than should be replaced by not less thanand less than should be replaced by not greater than. (Why not replace greater with greater-than-or-equal-to? You probably could in your head, but the mathematicians will tell you that it isn't the same thing.)

If the conditions are not met, then the hint is not used, and the insertion proceeds as if you had called `a.insert(t)` instead. (Note that GCC releases prior to 3.0.2 had a bug in the case with `hint == begin()` for the `map` and `set` classes. You should not use a hint argument in those releases.)

This behavior goes well with other containers' `insert()` functions which take an iterator: if used, the new item will be inserted before the iterator passed as an argument, same as the other containers.

Note also that the hint in this implementation is a one-shot. The older insertion-with-hint routines check the immediately surrounding entries to ensure that the new item would in fact belong there. If the hint does not point to the correct place, then no further local searching is done; the search begins from scratch in logarithmic time.

### bitset

#### Size Variable

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 chaptericular order:

- A very large N in `bitset<N>`.

- A container<bool>.

- Extremely weird solutions.

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 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 Independent 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...

Also note that the implementation of bitset used in libstdc++ has some extensions.

#### Type String

Bitmasks do not take char* nor const char* arguments in their constructors. This is something of an accident, but you can read about the problem: follow the library's Links from the homepage, and from the C++ information defect reflector link, select the library issues list. Issue number 116 describes the problem.

For now you can simply make a temporary string object using the constructor expression:

          std::bitset<5> b ( std::string(10110) );

instead of

          std::bitset<5> b ( 10110 );    // invalid

## Unordered Associative

### Hash Code

#### Hash Code Caching Policy

The unordered containers in libstdc++ may cache the hash code for each element alongside the element itself. In some cases not recalculating the hash code every time it's needed can improve performance, but the additional memory overhead can also reduce performance, so whether an unordered associative container caches the hash code or not depends on a number of factors. The caching policy for GCC 4.8 is described below.

The C++ standard requires that `erase` and `swap` operations must not throw exceptions. Those operations might need an element's hash code, but cannot use the hash function if it could throw. This means the hash codes will be cached unless the hash function has a non-throwing exception specification such as `noexcept` or `throw()`.

Secondly, libstdc++ also needs the hash code in the implementation of `local_iterator` and `const_local_iterator` in order to know when the iterator has reached the end of the bucket. This means that the local iterator types will embed a copy of the hash function when possible. Because the local iterator types must be DefaultConstructible and CopyAssignable, if the hash function type does not model those concepts then it cannot be embedded and so the hash code must be cached. Note that a hash function might not be safe to use when default-constructed (e.g if it a function pointer) so a hash function that is contained in a local iterator won't be used until the iterator is valid, so the hash function has been copied from a correctly-initialized object.

If the hash function is non-throwing, DefaultConstructible and CopyAssignable then libstdc++ doesn't need to cache the hash code for correctness, but might still do so for performance if computing a hash code is an expensive operation, as it may be for arbitrarily long strings. As an extension libstdc++ provides a trait type to describe whether a hash function is fast. By default hash functions are assumed to be fast unless the trait is specialized for the hash function and the trait's value is false, in which case the hash code will always be cached. The trait can be specialized for user-defined hash functions like so:

          #include <unordered_set>

          struct hasher
          {
            std::size_t operator()(int val) const noexcept
            {
              // Some very slow computation of a hash code from an int !
              ...
            }
          }

          namespace std
          {
            template<>
              struct __is_fast_hash<hasher> : std::false_type
              { };
          }

## Interacting with C

### Containers vs. Arrays

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.

    // beginof
    template<typename T>
      inline typename vector<T>::iterator
      beginof(vector<T> &v)
      { return v.begin(); }

    template<typename T, unsigned int sz>
      inline T*
      beginof(T (&array)[sz]) { return array; }

    // endof
    template<typename T>
      inline typename vector<T>::iterator
      endof(vector<T> &v)
      { return v.end(); }

    template<typename T, unsigned int sz>
      inline T*
      endof(T (&array)[sz]) { return array + sz; }

    // lengthof
    template<typename T>
      inline typename vector<T>::size_type
      lengthof(vector<T> &v)
      { return v.size(); }

    template<typename T, unsigned int sz>
      inline unsigned int
      lengthof(T (&)[sz]) { return sz; }

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.