Standard-Library Headers and Namespaces

Imagine writing a program using only the rules of the core language, with no prebuilt pieces to draw on. Every task that involves text, groups of values, output, or running work at the same time would have to be built from the ground up. Experienced C++ programmers almost never work this way. Instead, a body of libraries is developed first, and that body becomes the foundation for everything built afterward.

The difference in effort is large. Most programs are tedious to write in the bare language, while good libraries make nearly any task simple. The C++ standard library is the set of libraries that forms the foundation for most serious programming work. This article explains what that library is, how its specification relates to the implementations that deliver it, and where its boundary lies.

Before naming the facilities formally, trace a plain task and watch how the program's state grows. The source suggests this practice: start with a plain task, identify the kind of data involved, and ask which named facility fits each step. At the start nothing is stored, and each step adds one more piece of information the program has to keep track of.

This tour introduces eight named standard-library types. Each one stands for a family of facilities that the standard library provides. The goal at this stage is recognition, meaning you should know which facility handles which kind of job and how the most common uses look. Full mastery of each type comes later in the course.

Standard-library facilities are organized under a namespace, and the names of those facilities are grouped inside it. A name such as vector belongs to the standard library's namespace, so its full name is written with the namespace prefix, as in std::vector. The diagram below shows this containment: the standard namespace holds the facility names, and each name is a member of it.

Read the diagram from top to bottom. The namespace sits at the top as the container, and each facility is one of the names inside it. A name is usable in your program through its place in that namespace, which is why the same short name, vector for example, is always understood in terms of the standard namespace it belongs to. The diagram shows containment only; this tour does not go further into how headers are arranged.

The standard defines what the library must provide. Implementations are the concrete versions that supply those facilities on real systems. These are two different things. The specification is a document describing required facilities; an implementation is working software that delivers them. Several implementations can satisfy the same specification.

The diagram shows the relationship. One specification sits above several implementations, and each implementation supplies the same standard facilities. What stays the same across them is the interface the standard defines. What can differ is the concrete work each implementation does to deliver that interface on its own system.

The effort behind this arrangement is large. The library accounts for almost two thirds of the ISO C++ standard, and much thought went into its design. Much more went into its implementations, and much effort will continue into its maintenance and extension. Every complete C++ implementation includes the standard-library facilities described in this tour.

The advice in this tour is to explore the standard library and to prefer it over home-made alternatives. The reasoning follows from the arrangement above. A standard facility is defined once in the specification and supplied by every complete implementation, so code that uses it is meant to work wherever a conforming implementation is available. A home-made alternative carries no such guarantee and must be maintained by the programmer who wrote it.

The examples in this tour are written to be portable. They describe C++ as the standard defines it, so the same code is meant to work across conforming implementations. Once the basics are comfortable, the programmer is encouraged to explore the more extensive facilities that most systems provide beyond the standard.

Return to the text-report task and follow what the program holds at each point. The table records the stored state after each step, as the source describes: the program begins with nothing and gains one piece of information per step. This is the same growth you traced earlier, now written out as a running record.

Notice what this record does not show. It tells you which facility handles each step, not how any facility keeps its contents in memory. That detail belongs to the later, more detailed parts of the course.

The standard facilities are one layer. Outside that core, most implementations also offer graphical user interface systems, web interfaces, and database interfaces. Most application-development environments provide foundation libraries for their own corporate or industrial use. These are real and useful, but they are not part of the standard facilities this tour introduces, and they are not covered in this part of the course.

The comparison places the two sides side by side. The left column lists standard facilities that belong to every complete implementation. The right column lists systems supplied by particular environments. The boundary is about where a facility is defined and supplied, not about how useful it is.