C++ Library Overview

Using C++ Library Headers · C++ Library Conventions · Iostreams Conventions · Program Startup and Termination · Exceptions · C++11 Additions

All C++ library entities are declared or defined in one or more standard headers. To make use of a library entity in a program, write an include directive that names the relevant standard header. The Standard C++ library consists of 51 required headers. These C++ library headers (along with the additional 18 Standard C headers) constitute a hosted implementation of the C++ library: <algorithm>, <bitset>, <cassert>, <cctype>, <cerrno>, <cfloat>, <ciso646>, <climits>, <clocale>, <cmath>, <complex>, <csetjmp>, <csignal>, <cstdarg>, <cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, <cwchar>, <cwctype>, <deque>, <exception>, <fstream>, <functional>, <iomanip>, <ios>, <iosfwd>, <iostream>, <istream>, <iterator>, <limits>, <list>, <locale>, <map>, <memory>, <new>, <numeric>, <ostream>, <queue>, <set>, <sstream>, <stack>, <stdexcept>, <streambuf>, <string>, <strstream>, <typeinfo>, <utility>, <valarray>, and <vector>.

A freestanding implementation of the C++ library provides only a subset of these headers: <cstddef>, <cstdlib> (declaring at least the functions abort, atexit, and exit), <exception>, <limits>, <new>, <typeinfo>, and <cstdarg>.

The C++ library headers have two broader subdivisions, iostreams headers and STL headers.

The headers <array>, <random>, <regex>, <tuple>, <type_traits>, <unordered_map>, and <unordered_set>, are added by TR1, along with other additions to existing headers.

Using C++ Library Headers

You include the contents of a standard header by naming it in an include directive, as in:

#include <iostream>  /* include I/O facilities */

You can include the standard headers in any order, a standard header more than once, or two or more standard headers that define the same macro or the same type. Do not include a standard header within a declaration. Do not define macros that have the same names as keywords before you include a standard header.

A C++ library header includes any other C++ library headers it needs to define needed types. (Always include explicitly any C++ library headers needed in a translation unit, however, lest you guess wrong about its actual dependencies.) A Standard C header never includes another standard header. A standard header declares or defines only the entities described for it in this document.

Every function in the library is declared in a standard header. Unlike in Standard C, the standard header never provides a masking macro, with the same name as the function, that masks the function declaration and achieves the same effect.

All names other than operator delete and operator new in the C++ library headers are defined in the std namespace, or in a namespace nested within the std namespace. You refer to the name cin, for example, as std::cin. Note, however, that macro names are not subject to namespace qualification, so you always write __STD_COMPLEX without a namespace qualifier.

In some translation environments, including a C++ library header may hoist external names declared in the std namespace into the global namespace as well, with individual using declarations for each of the names. Otherwise, the header does not introduce any library names into the current namespace.

The C++ Standard requires that the C Standard headers declare all external names in namespace std, then hoist them into the global namespace with individual using declarations for each of the names. But in some translation environments the C Standard headers include no namespace declarations, declaring all names directly in the global namespace. Thus, the most portable way to deal with namespaces is to follow two rules:

Thus, if you want to call std::abort() to cause abnormal termination, you should include <cstdlib>. And if you want to call abort(), you should include <stdlib.h>.

Alternatively, you can write the declaration:

using namespace std;

which assuredly hoists all library names into the current namespace. If you write this declaration immediately after all include directives, you hoist the names into the global namespace. You can subsequently ignore namespace considerations in the remainder of the translation unit. You also avoid most dialect differences across different translation environments.

Unless specifically indicated otherwise, you may not define names in the std namespace, or in a namespace nested within the std namespace.

C++ Library Conventions

The C++ library obeys much the same conventions as the Standard C library, plus a few more outlined here.

An implementation has certain latitude in how it declares types and functions in the C++ library:

On the other hand, there are some restrictions you can count on:

Iostreams Conventions

The iostreams headers support conversions between text and encoded forms, and input and output to external files: <fstream>, <iomanip>, <ios>, <iosfwd>, <iostream>, <istream>, <ostream>, <sstream>, <streambuf>, and <strstream>.

The simplest use of iostreams requires only that you include the header <iostream>. You can then extract values from cin, to read the standard input. The rules for doing so are outlined in the description of the class basic_istream. You can also insert values to cout, to write the standard output. The rules for doing so are outlined in the description of the class basic_ostream. Format control common to both extractors and insertors is managed by the class basic_ios. Manipulating this format information in the guise of extracting and inserting objects is the province of several manipulators.

You can perform the same iostreams operations on files that you open by name, using the classes declared in <fstream>. To convert between iostreams and objects of class basic_string, use the classes declared in <sstream>. And to do the same with C strings, use the classes declared in <strstream>.

The remaining headers provide support services, typically of direct interest to only the most advanced users of the iostreams classes.

C++ Program Startup and Termination

A C++ program performs the same operations as does a C program program startup and at program termination, plus a few more outlined here.

Before the target environment calls the function main, and after it stores any constant initial values you specify in all objects that have static duration, the program executes any remaining constructors for such static objects. The order of execution is not specified between translation units, but you can nevertheless assume that some iostreams objects are properly initialized for use by these static constructors. These control text streams:

You can also use these objects within the destructors called for static objects, during program termination.

As with C, returning from main or calling exit calls all functions registered with atexit in reverse order of registry. An exception thrown from such a registered function calls terminate().


In this implementation, exception handling can be either enabled or disabled. This document describes all behavior as if exception handling is enabled. If exception handling is disabled, however:

Here, void _Raise() is a member function of class exception, the base class for all exceptions thrown by the library. It performs the following operations, in order:

  1. If a raise handler has been registered by an earlier call to the static member function exception:: _Set_raise_handler(void (*)(const exception&), then _Raise calls the raise handler.
  2. _Raise then calls the protected virtual member function void _Doraise(), which typically calls _Throw(*this) in any class derived from exception. (This ensures that the most derived version of the virtual public member function what gets called by _Throw, as outlined below.)
  3. _Raise then calls _Throw(*this).

The replaceable global function void _Throw(const exception& ex) never returns to its caller. If the pointer returned by ex.what() is not a null pointer, the function writes to the standard error output stream a diagnostic message that includes the null-terminated string designated by the pointer. In any event, the function then calls abort.

The net effect of all this machinery is to supply several levels of control, in lieu of the normal exception-handling machinery:

C++11 Additions

(Note: None of the features added with C++11 are a part of EC++.)

A number of new features are added with C++11, a revision of the C++ Standard intended to be finalized circa 2009. They are labeled as such throughout this document. Some features that are of particular interest:

A parameter of type initializer_list takes a brace-enclosed initializer list as its corresponding argument. It behaves just like a sequence of elements of type Ty.

An rvalue reference is indicated by && in a context where you can write & to indicate a reference. As a function parameter, an rvalue reference matches only an argument that is movable -- it will assuredly be destroyed at the end of the function-call expression, or the program promises that it will be destroyed before any further use. Hence, the function can commandeer data owned by the argument, thus moving data instead of copying it, so long as the resultant argument can be properly destroyed. (A function overload with an rvalue reference of the form T&& typically accompanies an older function overload with a corresponding const reference of the form const T&. The former can alter the (temporary) object, while the latter promises to leave the object unaltered.

Similarly, objects of some types can be swappable even if they cannot be copied or assigned.

A variadic template includes template parameters with ellipsis (...), each of which matches a comma-separated list of zero or more template parameters. The ellipsis notation can further be used in several ways within the template definition to indicate argument lists and derived type lists, among other things. Hence, a single variadic template can represent an open-ended set of templates that differ in the number of template parameters they accept.

See also the Table of Contents and the Index.

Copyright © 1992-2013 by P.J. Plauger. All rights reserved.