ISO C++ library

Most exception classes are defined in one of the standard headers <exception>, <stdexcept>, <new>, and <typeinfo>. The C++ 2011 revision of the standard added more exception types in the headers <functional>, <future>, <regex>, and <system_error>. The C++ 2017 revision of the standard added more exception types in the headers <any>, <filesystem>, <optional>, and <variant>. All exceptions thrown by the library have a base class of type std::exception, defined in <exception>. This type has no std::string member. Derived from this are several classes that may have a std::string member. A full hierarchy can be found in the source documentation.

The standard exception classes carry with them a single string as data (usually describing what went wrong or where the 'throw' took place). It's good to remember that you can add your own data to these exceptions when extending the hierarchy: struct My_Exception : public std::runtime_error { public: My_Exception (const string& whatarg) : std::runtime_error(whatarg), e(errno), id(GetDataBaseID()) { } int errno_at_time_of_throw() const { return e; } DBID id_of_thing_that_threw() const { return id; } protected: int e; DBID id; // some user-defined type };

The C and POSIX standards guarantee that errno is never set to zero by any library function. The C++ standard has less to say about when errno is or isn't set, but libstdc++ follows the same rule and never sets it to zero. On the other hand, there are few guarantees about when the C++ library sets errno on error, beyond what is specified for functions that come from the C library. For example, when std::stoi throws an exception of type std::out_of_range, errno may or may not have been set to ERANGE. Parts of the C++ library may be implemented in terms of C library functions, which may result in errno being set with no explicit call to a C function. For example, on a target where operator new uses malloc a failed memory allocation with operator new might set errno to ENOMEM. Which C++ library functions can set errno in this way is unspecified because it may vary between platforms and between releases.

In 1999, SGI added concept checkers to their implementation of the STL: code which checked the template parameters of instantiated pieces of the STL, in order to insure that the parameters being used met the requirements of the standard. For example, the Standard requires that types passed as template parameters to vector be "Assignable" (which means what you think it means). The checking was done during compilation, and none of the code was executed at runtime. Unfortunately, the size of the compiler files grew significantly as a result. The checking code itself was cumbersome. And bugs were found in it on more than one occasion. The primary author of the checking code, Jeremy Siek, had already started work on a replacement implementation. The new code was formally reviewed and accepted into the Boost libraries, and we are pleased to incorporate it into the GNU C++ library. The new version imposes a much smaller space overhead on the generated object file. The checks are also cleaner and easier to read and understand. They are off by default for all versions of GCC. They can be enabled at configure time with --enable-concept-checks. You can enable them on a per-translation-unit basis with -D_GLIBCXX_CONCEPT_CHECKS. Please note that the checks are based on the requirements in the original C++ standard, many of which were relaxed in the C++11 standard and so valid C++11 code may be incorrectly rejected by the concept checks. Additionally, some correct C++03 code might be rejected by the concept checks, for example template argument types may need to be complete when used in a template definition, rather than at the point of instantiation. There are no plans to address these shortcomings.