Specialized Containers in the C++ Standard Library

Most programs do real work by obtaining things from their environment and then using them. A program might reserve memory, open a file, take a lock so that only one part of the program touches shared data at a time, open a network socket, or hold a handle to a thread. The C++ Standard Library and the source material that introduces this topic call each of these things a resource.

The list of examples spans very different things: memory, locks, sockets, thread handles, and file handles. These share the same shape. A program obtains them, uses them, and is responsible for giving them back. The important idea is the shared lifecycle, not the particular kind of resource. Once you see that pattern, you can recognize resource handling in many places, even ones this article does not name.

Any resource moves through a cycle. It begins in an unacquired state, is acquired, is used for some work, and eventually reaches a point where it must be released. Follow one resource through a simple scenario and watch its state at each step. Suppose a program opens a file handle to read a configuration value. Before the open call, the handle is unacquired: the program does not have it. After the open call succeeds, the handle is acquired and held by the program. While the program reads from it, the handle is in use. When the program has finished reading, the handle must be released so that it is given back.

Notice where the release step sits in the cycle. It is the last transition, and it is the one most easily forgotten. Nothing visibly breaks at the moment it is skipped. The program keeps running, the file handle is simply still held when the program no longer needs it. That is why the lifecycle is worth keeping in mind from the very start of any resource-handling code.

The source calls a failure to release a resource in a timely manner a leak. The consequence does not appear immediately. For a long-running program, a leak can cause serious performance degradation and possibly a miserable crash. The problem accumulates: each unreleased resource is a little more that the program is holding onto without need.

The two columns of the diagram describe the same scenario with one difference: whether the final release step happened. In the left column the handle stays held after the work is done, and the cost grows over time. In the right column the handle is given back, and the program holds nothing it does not need.

This part of the library is introduced as a map of small, widely useful components in four groups. Resource management covers the smart pointers that help a program manage resources. Specialized containers are array, bitset, pair, and tuple. Function adaptors include iterator_traits, Type Predicates, and mem_fn(). Smart pointers are unique_ptr and shared_ptr. The source names these components without fully explaining them, so treat this section as a map and continue with the detailed material for each group.

The central observation of this group is that a function or a type does not need to be complicated, or tightly bound to a large cluster of other functions and types, to be valuable. Components like these mostly serve as building blocks. Larger library facilities are assembled from them, so understanding the small pieces helps when you later meet the larger ones.

The C++ Standard Library includes a group of containers that have specific uses. This article calls them specialized containers. They are the components the library offers for storing collections of values when a more targeted tool is needed than a general-purpose container. The source names four of them: array, bitset, pair, and tuple. Each one is a container in its own right, and each has its own purpose.

Read the diagram as a family relationship. The four containers are siblings, all grouped under specialized containers. The source does not rank them, and none is described as a version of another, so treat them as four separate tools that share a category.