Standard-Library Facilities Tour: vector and map

Imagine a program that must read text, store a collection of records, manage memory safely, and run work in parallel. You could try to write every one of those capabilities from scratch using only the core language rules. In practice, almost no serious program is built that way. Real software starts on top of a foundation of existing libraries, and the programmer's own code is the layer added on top.

This section introduces the part of that foundation that comes with C++ itself: the standard library. Before we look at any individual facility, we will trace what the library is, why it exists, and how its pieces relate to one another. The two facilities this article focuses on, vector and map, are examples of the containers you will meet as you go deeper.

The standard library is not an optional extra sitting beside the language. It is a large, deliberately designed part of C++. The specification of the standard library takes up almost two thirds of the ISO C++ standard. That proportion shows how much of the language's official definition is devoted to library facilities rather than to core language rules.

A programming language gives you the basic building blocks: how to compute, how to make decisions, and how to organize code into functions and types. Those building blocks are small. Trying to solve a large task with only them forces you to rebuild the same machinery again and again. The result is code that is tedious to write and easy to get wrong.

Libraries change that equation. Once a set of well-designed facilities exists, the work of a task can often be expressed in a few clear steps that name those facilities. The source puts the contrast plainly: most programs are tedious to write in the bare language, while nearly any task can be made simple with good libraries. The effort shifts from reinventing foundations to combining them.

The standard library is built in stages. A set of libraries is developed first, and then those libraries form the basis for further work. Each layer is therefore a starting point for the next layer of programs, so a programmer writes the application logic that is unique to the task instead of the machinery that every task shares.

This part of the course tours eight facilities: string, ostream, vector, map, unique_ptr, thread, regex, and complex. The tour is not meant to make you master every detail. Its purpose is to build a working sense of which facilities exist and what kinds of tasks they serve.

The diagram shows the eight facilities as direct members of the standard library. It does not explain how any one of them behaves. Each is treated in later parts of the tour, and the way a program reaches any of them is governed by the header and namespace conventions that come next in the course.

A vector is a contiguous sequence with index-based access. Its elements sit one after another, and you select an element by its position in that sequence. The diagram below uses three placeholder values to show the idea: index 0 is the first element, index 1 the next, and index 2 the last.

When the program writes v[2], it names the element at index 2, which here holds the placeholder value 30. The index is the way to reach the position; the elements themselves stay in their order. This is the shape that makes a vector a natural choice when position in a list matters.

A map is a collection of key-value pairs. Instead of selecting an element by its position, you look up a key and receive the value stored with it. The diagram uses placeholder names and scores to show the pairing.

Reading the diagram from the key side: the key bob is paired with the value 75. A lookup starts from the key and returns its matching value, while the position of the pair is not the point. This key-to-value idea is the reason map appears alongside vector in the tour: one answers where an element sits, the other answers what a named key is associated with.

The standard library is not the whole story of a real application. Most implementations also offer graphical user interface systems, web interfaces, and database interfaces. Application-development environments add foundation libraries built for particular corporate or industrial standards. These systems are useful, but they are not part of the standard library described in this course.