C++ Standard Library

Die C++-Standardbibliothek bietet eine breite Palette von Einrichtungen, die im standardkonformen C++ verwendbar sind.

Inhaltsverzeichnis 1 Kategorie 2 Bibliotheksinhalt 2.1 Header 3 C-Standardbibliothek 3.1 Namen assoziiert mit sicheren Funktionen in Standard C (seit C++17) 4 Verwendung der Bibliothek 4.1 Header einbinden 4.2 Header importieren 4.3 Module importieren 4.4 Bindung 5 Anforderungen an Standardbibliotheksimplementierungen 5.1 Garantien 5.2 Implementierungsfreiheit 6 Standardbibliothekshärtung 6.1 Elementfunktionen mit gehärteten Vorbedingungen 7 Anmerkungen 8 Fehlerberichte

Kategorie

Die Sprachunterstützungsbibliothek bietet Komponenten, die von bestimmten Teilen der C++-Sprache benötigt werden, wie Speicherallokation ( new / delete ) und Ausnahmebehandlung .

Die Concepts-Bibliothek beschreibt Bibliothekskomponenten, die C++-Programme zur Compilezeit-Validierung von Template-Argumenten und zur Funktionsauswahl basierend auf Typeigenschaften verwenden können.

(seit C++20)

Die Diagnosebibliothek bietet einen einheitlichen Rahmen zur Fehlerberichterstattung in C++-Programmen, einschließlich vordefinierter Ausnahmeklassen .

Die Speicherverwaltungsbibliothek bietet Komponenten zur Speicherverwaltung, einschließlich Smart Pointern und Scoped Allocator (seit C++11) .

Die Metaprogrammierungsbibliothek beschreibt Einrichtungen zur Verwendung in Templates und während konstanter Auswertung, einschließlich Type Traits , Integer Sequence , (seit C++14) und rationaler Arithmetik .

(seit C++11)

Die Allgemeine Hilfsbibliothek enthält Komponenten, die von anderen Bibliothekselementen verwendet werden, wie einen vordefinierten Speicher-Allokator für die dynamische Speicherverwaltung, und Komponenten, die als Infrastruktur in C++-Programmen dienen, wie Tupel und (seit C++11) Funktionswrapper .

Die Container , Iteratoren , Ranges (seit C++20) und Algorithmen -Bibliotheken bieten einem C++-Programm Zugriff auf eine Auswahl der am weitesten verbreiteten Algorithmen und Datenstrukturen.

Die String-Bibliothek bietet Unterstützung für die Manipulation von Text, der als homogene Sequenzen der folgenden Typen dargestellt wird: char , char8_t (seit C++20) , char16_t , char32_t (seit C++11) , wchar_t , und alle anderen zeichenähnlichen Typen.

Die Textverarbeitungsbibliothek bietet Regex-Matching und -Suche (seit C++11) , Hilfsmittel für Textformatierung (seit C++20) , Textkodierungsidentifikation (seit C++26) und Lokalisierungsfunktionen .

Die Numerik-Bibliothek bietet numerische Algorithmen und Komplexe-Zahlen -Komponenten, die die Unterstützung für numerische Verarbeitung erweitern. Die valarray -Komponente bietet Unterstützung für n-auf-einmal-Verarbeitung, die potenziell als parallele Operationen auf Plattformen implementiert ist, die solche Verarbeitung unterstützen. Die Zufallszahlen-Komponente bietet Einrichtungen zur Erzeugung von Pseudozufallszahlen. (seit C++11)

Die Zeitbibliothek bietet allgemein nützliche Zeitfunktionen.

Die Input/Output-Bibliothek stellt die iostream-Komponenten bereit, die den primären Mechanismus für die Eingabe und Ausgabe von C++-Programmen darstellen. Sie können mit anderen Elementen der Bibliothek verwendet werden, insbesondere mit Strings, Locales und Iteratoren.

Die Thread-Unterstützungsbibliothek bietet Komponenten zum Erstellen und Verwalten von Threads, einschließlich atomarer Operationen , gegenseitigem Ausschluss und Thread-Kommunikation.

(since C++11)

Die Execution-Support Bibliothek bietet ein Framework zur Verwaltung asynchroner Ausführung auf generischen Ausführungsressourcen.

(since C++26)

Bibliotheksinhalt

Die C++-Standardbibliothek stellt Definitionen für die Entitäten und Makros bereit, die in den Übersichten der C++-Standardbibliothek-Header beschrieben sind, sofern nicht anders angegeben.

Alle Bibliotheksentitäten außer operator new und operator delete sind innerhalb des Namensraums std oder in Namensräumen definiert, die innerhalb des Namensraums std geschachtelt sind (mit Ausnahme der Entitäten für die C-Standardbibliothekseinrichtungen, siehe unten). Es ist nicht spezifiziert, ob Namen, die in einem bestimmten Namensraum deklariert werden, direkt in diesem Namensraum oder in einem Inline-Namensraum innerhalb dieses Namensraums deklariert werden. (seit C++11)

Header

Jedes Element der C++-Standardbibliothek wird in einem Header deklariert oder definiert (je nach Anwendungsfall). Ein Header ist nicht notwendigerweise eine Quelldatei, noch sind die durch < und > begrenzten Sequenzen in Headernamen notwendigerweise gültige Quelldateinamen.

Die C++-Standardbibliothek stellt die C++-Bibliotheksheader und zusätzliche C++-Header für C-Bibliotheksfunktionen bereit (siehe " headers "-Seite für Beschreibungen):

C++-Bibliotheksheader
<algorithm>	<iomanip>	<list>	<ostream>	<streambuf>
<bitset>	<ios>	<locale>	<queue>	<string>
<complex>	<iosfwd>	<map>	<set>	<typeinfo>
<deque>	<iostream>	<memory>	<sstream>	<utility>
<exception>	<istream>	<new>	<stack>	<valarray>
<fstream>	<iterator>	<numeric>	<stdexcept>	<vector>
<functional>	<limits>
In C++11 hinzugefügte Header
<array>	<condition_variable>	<mutex>	<scoped_allocator>	<type_traits>
<atomic>	<forward_list>	<random>	<system_error>	<typeindex>
<chrono>	<future>	<ratio>	<thread>	<unordered_map>
<codecvt>	<initializer_list>	<regex>	<tuple>	<unordered_set>
In C++14 hinzugefügte Header
<shared_mutex>
In C++17 hinzugefügte Header
<any>	<execution>	<memory_resource>	<string_view>	<variant>
<charconv>	<filesystem>	<optional>
In C++20 hinzugefügte Header
<barrier>	<concepts>	<latch>	<semaphore>	<stop_token>
<bit>	<coroutine>	<numbers>	<source_location>	<syncstream>
<compare>	<format>	<ranges>	<span>	<version>
In C++23 hinzugefügte Header
<expected>	<flat_set>	<mdspan>	<spanstream>	<stdfloat>
<flat_map>	<generator>	<print>	<stacktrace>
In C++26 hinzugefügte Header
<contracts>	<hazard_pointer>	<inplace_vector>	<rcu>	<text_encoding>
<debugging>	<hive>	<linalg>	<simd>
Entfernte Header
<codecvt>	(seit C++11) (veraltet in C++17) (entfernt in C++26)
<strstream>	(veraltet in C++98) (entfernt in C++26)

C++-Header für C-Bibliotheksfunktionen
<cassert>	<clocale>	<cstdarg>	<cstring>
<cctype>	<cmath>	<cstddef>	<ctime>
<cerrno>	<csetjmp>	<cstdio>	<cwchar>
<cfloat>	<csignal>	<cstdlib>	<cwctype>
<climits>
In C++11 hinzugefügte Header
<cfenv>	<cinttypes>	<cstdint>	<cuchar>
Entfernte Header
<ccomplex>	(seit C++11) (veraltet in C++17) (entfernt in C++20)
<ciso646>	(entfernt in C++20)
<cstdalign>	(seit C++11) (veraltet in C++17) (entfernt in C++20)
<cstdbool>	(seit C++11) (veraltet in C++17) (entfernt in C++20)
<ctgmath>	(seit C++11) (veraltet in C++17) (entfernt in C++20)

Eine freestanding implementation hat einen implementierungsdefinierten Satz von Headern, siehe hier für die Mindestanforderungen an den Satz von Headern.

C-Standardbibliothek

Die C++-Standardbibliothek stellt auch die Einrichtungen der C-Standardbibliothek zur Verfügung, entsprechend angepasst um statische Typsicherheit zu gewährleisten. Die Beschreibungen vieler Bibliotheksfunktionen stützen sich auf die C-Standardbibliothek für die Semantik dieser Funktionen.

In einigen Fällen können die in Standard C++ spezifizierten Signaturen von den Signaturen in der C-Standardbibliothek abweichen, und zusätzliche Überladungen können deklariert werden, aber das Verhalten und die Vorbedingungen (einschließlich jener, die durch C's restrict impliziert werden) (seit C++17) sind gleich, sofern nicht anders angegeben.

Aus Gründen der Kompatibilität mit der C-Standardbibliothek stellt die C++-Standardbibliothek die unten aufgeführten C-Header bereit. Diese Header sind nur für Interoperabilität gedacht. Es ist möglich, dass C++-Quelldateien einen dieser Header einbinden müssen, um gültiger ISO-C-Code zu sein. Quelldateien, die nicht gleichzeitig gültiger ISO-C-Code sein sollen, sollten keine der C-Header verwenden. Siehe hier für Beschreibungen.

C-Header
<assert.h>	<limits.h>	<stdarg.h>	<string.h>
<ctype.h>	<locale.h>	<stddef.h>	<time.h>
<errno.h>	<math.h>	<stdio.h>	<wchar.h>
<float.h>	<setjmp.h>	<stdlib.h>	<wctype.h>
<iso646.h>	<signal.h>
In C++11 hinzugefügte Header
<complex.h>	<inttypes.h>	<stdbool.h>	<tgmath.h>
<fenv.h>	<stdalign.h>	<stdint.h>	<uchar.h>
In C++23 hinzugefügte Header
<stdatomic.h>
In C++26 hinzugefügte Header
<stdbit.h>	<stdchkint.h>

Sofern nicht anders angegeben, entspricht der Inhalt jedes Headers c xxx dem des entsprechenden Headers xxx .h wie im C-Standardbibliothek spezifiziert. In der C++-Standardbibliothek befinden sich die Deklarationen (außer Namen, die in C als Makros definiert sind) jedoch im Namensbereich des Namespace std . Es ist nicht spezifiziert, ob diese Namen (einschließlich hinzugefügter Überladungen) zuerst im globalen Namensbereich deklariert und dann durch explizite using-Deklarationen in den Namespace std injiziert werden.

Namen, die in C als Makros definiert sind ( assert , offsetof , setjmp , va_arg , va_end und va_start ) müssen in der C++-Standardbibliothek als Makros definiert sein, selbst wenn C die Implementierung als Funktionen erlaubt.

Namen, die in C als Funktionen definiert sind, müssen in der C++-Standardbibliothek als Funktionen definiert werden. Dies verbietet die in C erlaubte Praxis, zusätzlich zum Funktionsprototypen ein maskierendes Makro bereitzustellen. Die einzige Möglichkeit, äquivalentes Inline-Verhalten in C++ zu erreichen, ist die Bereitstellung einer Definition als externe inline-Funktion .

Bezeichner, die Schlüsselwörter oder Operatoren in C++ sind, können in C++-Standardbibliotheksheadern nicht als Makros definiert werden. Insbesondere hat das Einbinden der Standardheader-Datei <iso646.h> keine Auswirkung.

Namen assoziiert mit sicheren Funktionen im Standard C (seit C++17)

Wenn irgendein C++-Header eingebunden wird, ist implementierungsdefiniert, ob einer der folgenden C-Standard-Annex-K-Namen im globalen Namensraum deklariert wird (keiner davon wird im Namensraum std deklariert):

C-Standard Anhang K Namen
abort_handler_s	mbstowcs_s	strncat_s	vswscanf_s
asctime_s	memcpy_s	strncpy_s	vwprintf_s
bsearch_s	memmove_s	strtok_s	vwscanf_s
constraint_handler_t	memset_s	swprintf_s	wcrtomb_s
ctime_s	printf_s	swscanf_s	wcscat_s
errno_t	qsort_s	tmpfile_s	wcscpy_s
fopen_s	RSIZE_MAX	TMP_MAX_S	wcsncat_s
fprintf_s	rsize_t	tmpnam_s	wcsncpy_s
freopen_s	scanf_s	vfprintf_s	wcsnlen_s
fscanf_s	set_constraint_handler_s	vfscanf_s	wcsrtombs_s
fwprintf_s	snprintf_s	vfwprintf_s	wcstok_s
fwscanf_s	snwprintf_s	vfwscanf_s	wcstombs_s
gets_s	sscanf_s	vprintf_s	wmemcpy_s
gmtime_s	mbstowcs_s	vscanf_s	vswscanf_s
abort_handler_s	strcat_s	vsnprintf_s	wmemmove
ignore_handler_s	strcpy_s	vsnwprintf_s	wprintf_s
localtime_s	strerrorlen_s	vsprintf_s	wscanf_s
L_tmpnam_s	strerror_s	vsscanf_s
mbsrtowcs_s	strlen_s	vswprintf_s

Verwendung der Bibliothek

Header-Dateien einbinden

Die Entitäten in der C++-Standardbibliothek sind in Headern definiert, deren Inhalte einer Translation Unit verfügbar gemacht werden, wenn sie die entsprechende #include Präprozessor-Direktive enthält.

Eine Übersetzungseinheit kann Bibliotheksheader in beliebiger Reihenfolge einbinden. Jeder Header kann mehr als einmal eingebunden werden, wobei dies keinen anderen Effekt hat als das einmalige Einbinden, außer dass der Effekt des Einbindens von entweder <cassert> oder <assert.h> jedes Mal von der lexikalisch aktuellen Definition von NDEBUG abhängt.

Eine Übersetzungseinheit kann einen Header nur außerhalb jeglicher Deklaration oder Definition und lexikalisch vor der ersten Referenz in dieser Übersetzungseinheit auf eine der in diesem Header deklarierten Entitäten einbinden. Es ist keine Diagnose erforderlich.

In Modul-Einheiten können Header nur in globalen Modulfragmenten eingebunden werden.

(since C++20)

Importieren von Headern Die C++-Bibliotheksheader , oder für eine eigenständige Implementierung die Teilmenge solcher Header, die von der Implementierung bereitgestellt werden, werden zusammen als importierbare C++-Bibliotheksheader bezeichnet. Die Inhalte importierbarer C++-Bibliotheksheader werden einer Übersetzungseinheit verfügbar gemacht, wenn sie die entsprechende Importdeklaration enthält.

(since C++20)

Importieren von Modulen Die C++-Standardbibliothek stellt folgende C++-Bibliotheksmodule bereit: Das benannte Modul std exportiert Deklarationen im Namespace std , die von den importierbaren C++-Bibliotheksheadern bereitgestellt werden (z.B. std::rotr aus <bit> ) und den C++-Headern für C-Bibliotheksfunktionen (z.B. std::puts aus <cstdio> ). Zusätzlich exportiert es Deklarationen im globalen Namespace für die Speicherallokierung und -freigabe , die von <new> bereitgestellt werden (z.B. ::operator new ). Das benannte Modul std. compat exportiert die gleichen Deklarationen wie das benannte Modul std und zusätzlich Deklarationen im globalen Namespace, die den Deklarationen im Namespace std entsprechen, die von den C++-Headern für C-Bibliotheksfunktionen bereitgestellt werden (z.B. ::fclose ). Für jede Deklaration in der Standardbibliothek gilt: das Modul, an das sie angehängt ist , ist nicht spezifiziert, und sie bezeichnet dieselbe Entität , unabhängig davon, ob sie durch das Einbinden eines Headers, das Importieren einer Header-Unit oder das Importieren eines C++-Bibliotheksmoduls erreichbar gemacht wurde.

(since C++23)

Verknüpfung

Entitäten in der C++-Standardbibliothek haben storage duration#external linkage . Sofern nicht anders angegeben, haben Objekte und Funktionen standardmäßig extern "C++" linkage .

Ob ein Name aus der C-Standardbibliothek, der mit externer Verknüpfung deklariert ist, extern "C" oder extern "C++" Verknüpfung besitzt, ist implementierungsdefiniert. Der C++-Standard empfiehlt in diesem Fall die Verwendung von extern "C++" .

Objekte und Funktionen, die in der Bibliothek definiert sind und von einem C++ Programm benötigt werden, werden vor dem Programmstart in das Programm eingebunden.

Anforderungen an Standardbibliothek-Implementierungen

Garantien

Ein C++-Header muss Deklarationen und Definitionen bereitstellen, die darin erscheinen

• die Synopsis dieses Headers, oder
• die Synopsis eines anderen Headers, der in der Synopsis dieses Headers enthalten zu sein scheint.

Für Typen und Makros, die in mehreren Headern definiert sind (wie z.B. NULL ), verletzt das Inkludieren beliebig vieler dieser Header in beliebiger Reihenfolge niemals die One Definition Rule .

Sofern nicht anders angegeben, können alle objektähnlichen Makros der C-Standardbibliothek, die zu ganzzahligen konstanten Ausdrücken expandieren, in #if Präprozessordirektiven verwendet werden.

Das Aufrufen einer Standardbibliothek-Nicht-Mitgliedsfunktionssignatur führt immer dazu, dass tatsächlich diese Funktion aufgerufen wird. Daher kann eine konforme Standardbibliotheksimplementierung keine zusätzlichen Nicht-Mitgliedsfunktionen definieren, die von einem gültigen C++-Programm aufgerufen werden könnten.

Nicht-Member-Funktionssignaturen werden niemals mit zusätzlichen Default Arguments deklariert.

Sofern nicht anders angegeben, verwenden Aufrufe durch Funktionen in der Standardbibliothek an Nicht-Operator-, Nicht-Member-Funktionen keine Funktionen aus einem anderen namespace , die durch argument-dependent name lookup gefunden werden.

Für jede friend-Deklaration einer Funktion (Template) innerhalb einer Klassen-(Template-)Definition wird keine weitere Deklaration für diese Funktion (Template) bereitgestellt.

Standardbibliothek-Funktionssignaturen dürfen nur als constexpr deklariert werden, wenn sie constexpr sein müssen (libstdc++ cmath ist hier bekanntermaßen nicht konform ). Wenn ein Header nicht-definierende Deklarationen von constexpr-Funktionen oder Konstruktoren bereitstellt, sollten die entsprechenden Definitionen ebenfalls innerhalb dieses Headers bereitgestellt werden. Sofern nicht anders angegeben, muss jede Standardbibliotheksfunktion die folgenden Anforderungen erfüllen, um Datenrennen zu verhindern: Eine C++-Standardbibliotheksfunktion darf nicht (direkt oder indirekt) auf Objekte zugreifen, die von anderen Threads als dem aktuellen Thread zugänglich sind, es sei denn, die Objekte werden (direkt oder indirekt) über die Funktionsargumente inklusive this zugänglich gemacht. Eine C++-Standardbibliotheksfunktion darf nicht (direkt oder indirekt) Objekte modifizieren, die von anderen Threads als dem aktuellen Thread zugänglich sind, es sei denn, die Objekte werden (direkt oder indirekt) über die nicht-konstanten Funktionsargumente inklusive this zugänglich gemacht. Beispielsweise darf ein Objekt mit statischer Speicherdauer nicht ohne Synchronisierung für interne Zwecke verwendet werden, da dies selbst in Programmen, die keine Objekte explizit zwischen Threads teilen, zu Datenrennen führen kann. Eine C++-Standardbibliotheksfunktion darf nicht indirekt auf Objekte zugreifen, die über ihre Argumente oder über Elemente ihrer Container -Argumente zugänglich sind, außer durch Aufruf der von ihrer Spezifikation für diese Containerelemente geforderten Funktionen. Eine Operation auf Iteratoren , die durch Aufruf einer Standardbibliotheks-Container- oder String-Memberfunktion erhalten wurden, kann auf den zugrundeliegenden Container zugreifen, ihn aber nicht modifizieren. Insbesondere stehen Container-Operationen, die Iteratoren ungültig machen, in Konflikt mit Operationen auf Iteratoren, die diesem Container zugeordnet sind. Eine C++-Standardbibliotheksfunktion darf Operationen nur dann ausschließlich innerhalb des aktuellen Threads ausführen, wenn diese Operationen sichtbare Auswirkungen für Benutzer haben. Operationen ohne sichtbare Seiteneffekte können parallelisiert werden.

(seit C++11)

Für jede Klasse, die in der C++-Standardbibliothek definiert ist und von einer anderen in der C++-Standardbibliothek definierten Klasse abgeleitet werden muss,

• die Basisklasse muss virtual sein, wenn sie als virtual spezifiziert ist,
• die Basisklasse kann nicht virtual sein, wenn sie nicht als virtual spezifiziert ist, und
• sofern nicht anders angegeben, sollen Typen mit unterschiedlichen Namen unterschiedliche Typen sein.

Sofern nicht anders angegeben, sind alle im C++-Standardbibliothek spezifizierten Typen keine final Typen.

(seit C++11)

Wenn eine Funktion in der C++-Standardbibliothek spezifiziert ist, eine Exception (in einer bestimmten Situation) eines gegebenen Typs zu werfen, kann die geworfene Exception nur diesen Typ oder einen davon abgeleiteten Typ haben, sodass ein Exception-Handler für den Basistyp sie abfangen kann.

Funktionen aus der C-Standardbibliothek können nur dann Ausnahmen werfen, wenn eine solche Funktion eine programmseitig bereitgestellte Funktion aufruft, die eine Ausnahme wirft ( qsort() und bsearch() erfüllen diese Bedingung).

Destruktoroperationen, die in der C++-Standardbibliothek definiert sind, werfen niemals Ausnahmen aus. Jeder Destruktor in der C++-Standardbibliothek verhält sich so, als hätte er eine nicht-werfende Ausnahmespezifikation .

Wenn eine Funktion in der C++-Standardbibliothek Fehler über ein std::error_code -Objekt meldet, muss dessen category() -Member für Fehler, die vom Betriebssystem stammen, std::system_category() zurückgeben, oder eine Referenz auf ein implementierungsdefiniertes std::error_category -Objekt für Fehler aus anderen Quellen. Die möglichen Werte von value() für jede dieser Fehlerkategorien sollten definiert sein. Objekte von Typen, die in der C++-Standardbibliothek definiert sind, können verschoben werden . Verschiebeoperationen können explizit spezifiziert oder implizit generiert werden. Sofern nicht anders angegeben, befinden sich solche verschobenen Objekte in einem gültigen, aber unspezifizierten Zustand. Ein Objekt eines in der C++-Standardbibliothek definierten Typs kann sich selbst zugewiesen werden . Sofern nicht anders angegeben, versetzt eine solche Zuweisung das Objekt in einen gültigen, aber unspezifizierten Zustand.

(seit C++11)

Implementierungsfreiheit

Es ist nicht spezifiziert, ob irgendwelche Member- oder Non-Member-Funktionen in der C++-Standardbibliothek als inline definiert sind.

Für eine nicht- virtuelle C++ Standardbibliothek-Memberfunktion kann ein anderer Satz von Memberfunktionssignaturen deklariert werden, vorausgesetzt, dass jeder Aufruf dieser Memberfunktion, der eine Überladung aus dem gegebenen Satz von Deklarationen auswählen würde, sich so verhält, als ob diese Überladung ausgewählt worden wäre. Dies erlaubt beispielsweise:

• Hinzufügen von Parametern mit Standardargumenten,
• Ersetzen einer Memberfunktion mit Standardargumenten durch zwei oder mehr Memberfunktionen mit äquivalentem Verhalten, oder
• Hinzufügen zusätzlicher Signaturen für einen Memberfunktionsnamen.

Sofern nicht anders angegeben, ist implementierungsdefiniert, welche Funktionen in der C++-Standardbibliothek rekursiv wieder eintretbar sein können.

C++-Standardbibliotheksimplementierungen können ihre eigenen internen Objekte zwischen Threads teilen, wenn diese Objekte für Benutzer nicht sichtbar sind und gegen Datenrennen geschützt sind.

(since C++11)

Es ist nicht spezifiziert, ob irgendeine Funktionssignatur oder Klasse in der C++-Standardbibliothek ein Freund einer anderen Klasse in der C++-Standardbibliothek ist.

Die hier beschriebenen Namen und globalen Funktionssignaturen hier sind für die Implementierung reserviert.

Jede Klasse in der C++-Standardbibliothek kann von einer Klasse mit einem für die Implementierung reservierten Namen abgeleitet werden. Wenn eine in der C++-Standardbibliothek definierte Klasse von anderen Klassen in der C++-Standardbibliothek abgeleitet werden muss, kann diese Klasse direkt von der erforderlichen Basisklasse oder indirekt über eine Hierarchie von Basisklassen mit für die Implementierung reservierten Namen abgeleitet werden.

Wenn eine Funktion in der C++-Standardbibliothek nicht als Ausnahme werfend spezifiziert ist, aber keine nicht-werfende Ausnahmespezifikation besitzt, ist die geworfene Ausnahme implementierungsdefiniert, jedoch sollte ihr Typ std::exception oder ein davon abgeleiteter Typ sein.

Die Ausnahmespezifikation für eine nicht-virtuelle Funktion kann durch Hinzufügen einer nicht-werfenden Ausnahmespezifikation verstärkt werden.

Standardbibliothek-Härtung Eine Implementierung kann eine gehärtete Implementierung  sein, ob die Implementierung gehärtet ist, ist implementierungsdefiniert. Einige Standardbibliothek-Memberfunktionen (und Memberfunktions-Templates) haben gehärtete Vorbedingungen  . Wenn eine solche Funktion aufgerufen wird: Falls die Implementierung gehärtet ist, werden vor allen anderen beobachtbaren Seiteneffekten der Funktion eine oder mehrere Contract-Assertions , deren Prädikate wie in der gehärteten Precondition beschrieben sind, mit einer Checking-Semantik ausgewertet. Falls eine dieser Assertions mit einer Non-Terminating-Semantik ausgewertet wird und der Contract-Violation-Handler zurückkehrt, ist das Verhalten undefiniert. Falls die Implementierung nicht gehärtet ist, ist das Verhalten undefiniert, wenn eine gehärtete Precondition verletzt wird. Memberfunktionen mit verstärkten Vorbedingungen Kategorie Sequenzcontainer Container-Views String-(View)-Klassen Allgemeine Utilities Numerische Arrays Klasse array vector inplace_vector deque list forward_list span mdspan basic_string basic_string_view bitset optional expected valarray (Konstruktor) span mdspan Elementzugriff operator* operator* operator* operator-> operator-> operator-> operator[] operator[] operator[] operator[] operator[] operator[] operator[] operator[] operator[] operator[] operator[] front front front front front front front front front front back back back back back back back back back error error Teilansichten first first last last subspan subspan Modifikatoren pop_front pop_front pop_front pop_front pop_back pop_back pop_back pop_back pop_back pop_back remove_prefix remove_prefix remove_suffix remove_suffix

(seit C++26)

Hinweise

libstdc++ , libc++ und STL unterstützen alle die Verwendung von Standardbibliotheksmodulen im C++20-Modus.

Feature-Test Makro	Wert	Std	Feature
__cpp_lib_modules	202207L	(C++23)	Standardbibliothek-Module std und std. compat
Nur gehärtete Implementierung
__cpp_lib_hardened_array	202502L	(C++26)	Gehärtetes std::array
__cpp_lib_hardened_basic_string	202502L	(C++26)	Gehärtetes std::basic_string
__cpp_lib_hardened_basic_string_view	202502L	(C++26)	Gehärtetes std::basic_string_view
__cpp_lib_hardened_bitset	202502L	(C++26)	Gehärtetes std::bitset
__cpp_lib_hardened_deque	202502L	(C++26)	Gehärtetes std::deque
__cpp_lib_hardened_expected	202502L	(C++26)	Gehärtetes std::expected
__cpp_lib_hardened_forward_list	202502L	(C++26)	Gehärtetes std::forward_list
__cpp_lib_hardened_inplace_vector	202502L	(C++26)	Gehärtetes std::inplace_vector
__cpp_lib_hardened_list	202502L	(C++26)	Gehärtetes std::list
__cpp_lib_hardened_mdspan	202502L	(C++26)	Gehärtetes std::mdspan
__cpp_lib_hardened_optional	202502L	(C++26)	Gehärtetes std::optional
__cpp_lib_hardened_span	202502L	(C++26)	Gehärtetes std::span
__cpp_lib_hardened_valarray	202502L	(C++26)	Gehärtetes std::valarray
__cpp_lib_hardened_vector	202502L	(C++26)	Gehärtetes std::vector

Fehlerberichte

Die folgenden verhaltensändernden Fehlerberichte wurden rückwirkend auf zuvor veröffentlichte C++-Standards angewendet.

DR	Angewendet auf	Verhalten wie veröffentlicht	Korrigiertes Verhalten
LWG 1	C++98	die Sprachverknüpfungen der Namen aus der C-Standardbibliothek waren nicht spezifiziert	sie sind implementierungsdefiniert
LWG 119	C++98	die Ausnahmespezifikationen virtueller Funktionen konnten verstärkt werden	nur erlaubt für nicht-virtuelle Funktionen
LWG 147	C++98	die Spezifikation für Nicht-Member-Funktionen betrachtete nur globale Funktionen	berücksichtigt auch nicht-globale Funktionen
LWG 225	C++98	Standardbibliotheksfunktionen könnten Nicht-Member-Funktionen aus anderen Namensräumen durch argumentabhängige Suche aufrufen	verboten, sofern nicht anders angegeben
LWG 336	C++98	<strstream> war kein C++-Bibliotheksheader	es ist ein C++-Bibliotheksheader
LWG 343	C++98	Bibliotheksheader-Abhängigkeiten waren nicht spezifiziert	spezifiziert (in Synopsen aufgelistet)
LWG 456	C++98	C++-Header für C-Bibliothekseinrichtungen konnten nur Definitionen im Namensraum std bereitstellen	dürfen im globalen Namensraum definieren und dann in Namensraum std injizieren
LWG 465	C++98	Bezeichner, die Schlüsselwörter oder Operatoren in C++ sind, konnten als Makros in C++-Standardbibliotheksheadern definiert werden (nur <ciso646> ist verpflichtet, sie nicht als Makros zu definieren)	alle C++-Standard- bibliotheksheader dürfen sie nicht als Makros definieren
LWG 1178	C++98	C++-Header müssen einen C++-Header einbinden, der benötigte Definitionen enthält	C++-Header müssen Deklarationen und Definitionen bereitstellen, die direkt oder indirekt in ihrer Synopsis enthalten sind
LWG 2013	C++11	es war nicht spezifiziert, ob Funktionen, die nicht vom Standard als constexpr gefordert werden, als constexpr deklariert werden können	verboten
LWG 2225	C++98	eine Diagnose war erforderlich, wenn ein Header an einer falschen Position eingebunden wird	keine Diagnose ist in diesem Fall erforderlich