Ressourcenverwaltung

C++ hat keine Garbage Collection, allerdings gibt es Bestrebungen, Garbage-Collection durch Bibliotheken oder durch Aufnahme in den Sprachstandard zu ermöglichen. Siehe auch Boehm-Speicherbereinigung.

Es ist möglich die Speicherverwaltung von C (malloc/realloc/free) zu verwenden; zur Implementierung von Low-Level-Funktionen in Bibliotheken wie der C++-Standardbibliothek ist dies zum Zugriff auf C Bibliotheksfunktionen notwendig. In allgemeinem C++-Code wird hiervon jedoch dringend abgeraten. Stattdessen ist es dort üblich, die Speicherverwaltung von der C++-Standardbibliothek übernehmen zu lassen, indem man die angebotenen Containerklassen verwendet.

Andere Ressourcen, z. B. Dateihandles oder Netzwerksockets werden in C++ üblicherweise in eigenen Klassen mit dem Prinzip RAII verwaltet, um das automatische Aufräumen nach der Verwendung sicherzustellen. Dies ist konzeptionell in anderen Programmiersprachen oft mit der Implementierung spezieller Basisklassen/Schnittstellen gestaltet – wie z. B. „AutoCloseable“ in Java oder „IDisposable“ in C#. In anderen Programmiersprachen benötigen diese nicht verwalteten Ressourcen oft ein spezielles Handling (z. B. „using“ Schlüsselwort in C#), um die Lebenszeit dieser Objekte Ausnahmesicher in Verbindung mit dem Garbage Collector zu verwalten. Die RAII basierten Implementierungen in C++ sind konzeptbedingt nicht anfällig bezüglich dieser Probleme da Speicher in C++ keinen Sonderstatus als Ressource hat. Eine korrekte Implementierung der Objektlebenszeit garantiert hier die Freigabe aller Ressourcen.

Für Verweise auf Objekte werden üblicherweise Referenzen verwendet, solange der Verweis das Objekt nicht besitzen soll – z. B. als Parameter bei Funktionsaufrufen. Um den Besitz von dynamisch allokierten Objekten zu verwalten werden üblicherweise Smart Pointer eingesetzt, welche die Destruktion und Speicherfreigabe übernehmen. Die Standardbibliothek unterscheidet hier strikt den Besitz. Während beim unique_ptr nur dieser Zeiger den Speicher besitzt, kann der Besitz des Speichers beim shared_ptr zwischen mehreren Zeigerinstanzen geteilt werden. Technisch realisiert ist dies beim shared_ptr meist mit Reference counting.

Unvollständige Objektorientierung

Undefiniertes Verhalten

Das Verhalten von einigen Sprachkonstrukten ist nicht definiert. Dies bedeutet, dass der Standard weder vorgibt noch empfiehlt, was in einem solchen Fall passiert. Die Auswirkungen reichen von Implementierungsabhängigkeit (d. h. je nach Zielrechner und Compiler kann sich das Konstrukt unterschiedlich verhalten) über unsinnige Ergebnisse oder Programmabstürze bis hin zu Sicherheitslücken. Einige dieser Freiheiten des Compilers lassen zusätzliche Optimierungen des Codes zu.

Es kommt zu unterschiedlichem Verhalten bei

• verschiedenen Compilern
• verschiedenen Compiler-Versionen
• verschiedener Architektur (ARM, x86, x64)
• verschiedenen Optimierungseinstellungen (Debug, Release, Optimierung)
• ausgewählter Befehlssatz, Aufrufkonventionen, u. v. a. m.

Quellcode mit Codepassagen mit undefiniertem Verhalten kann nach der Kompilierung unerwartetes und absurd erscheinenden Verhalten zeigen. So werden zu spät durchgeführte Überprüfungen wegoptimiert oder Schleifen, die auf einen ungültigen Index eines Arrays zugreifen, durch leere Endlosschleifen ersetzt.

Wichtig für das Verständnis von undefiniertem Verhalten ist insbesondere, dass niemals nur eine einzelne Operation ungültig ist, sondern das gesamte Programm ungültig wird und kein wohlgeformtes C++ mehr darstellt. Der Grund ist, dass manche Arten von „undefiniertem Verhalten“ Auswirkungen auf ganz andere, auch in sich korrekte, Programmteile haben und deren Verhalten beeinflussen können, beispielsweise bei Pufferüberläufen oder der unbeabsichtigten Änderung von Prozessor-Flags, die durch eine ungültige arithmetische Operation verursacht wurde und die nachfolgenden Berechnungen beeinflussen kann.

Beispiele für undefiniertes Verhalten:

• Überlauf von vorzeichenbehafteten Ganzzahlen (auch z. B. bei Umwandlung von unsigned int nach int)
• Nullzeiger-Dereferenzierungen
• Arrayzugriffe mit ungültigem Index
• Schiebeoperationen mit einer Schiebeweite, die negativ oder größergleich der Zahl der Bits des zu schiebenden Typs ist
• Division durch null mit integralen Datentypen
• Weglassen des return-Statements in Funktionen mit Rückgabewert (die Hauptfunktion main bildet die einzige Ausnahme)
• Ein Nebeneffekt ändert eine Variable, die mehrmals in dem Ausdruck (v[i] = i++;) oder in der Argumentliste (f(i, i++);) vorkommt (die Auswertungsreihenfolge von Teilausdrücken und Funktionsargumenten ist nicht festgelegt)

Einerseits ist das hieraus resultierende nichtdeterministische Laufzeitverhalten, insbesondere bei kleinen Änderungen der Plattform, mindestens als Risiko, in der Praxis oft aber als klarer Nachteil einzustufen. Andererseits werden hierdurch schnellere Programme ermöglicht, da Gültigkeitsüberprüfungen weggelassen werden können und der Compiler zudem oft Programmteile stärker optimieren kann, indem er Randfälle als per Definition ausgeschlossen ignoriert.

Ein oft nicht wahrgenommener Vorteil ist darüber hinaus, dass dadurch, dass undefiniertes Verhalten praktisch nur in äußerst fragwürdigen Konstrukten auftritt, die aber nicht zwingend während des Kompilierens feststellbar sind, unsemantischer oder anderweitig suboptimaler Code gewissermaßen verboten wird.

Beispielsweise besteht eine illegale Art zu prüfen, ob die Summe zweier positiver Ganzzahlen ${\displaystyle a}$ und ${\displaystyle b}$ vom Typ ‚int‘ verlustfrei wieder in einem ‚int‘ abgebildet werden kann, daraus, zu schauen, ob ihre Summe größer 0 ist (bei Überlauf entsteht auf den meisten Computern durch die Zweierkomplement-Arithmetik eine negative Zahl). Eine derartige Überprüfung ist allerdings aus mathematischer Sicht nicht besonders sinnvoll. Eine bessere (semantischere) Herangehensweise ist hier, die eigentliche Frage, ob ${\displaystyle a+b\leq \mathrm {INT\_MAX} }$, wobei ${\displaystyle \mathrm {INT\_MAX} }$ die größte in einem ‚int‘ darstellbare Zahl ist, nach der mathematisch validen Umformung zu ${\displaystyle a\leq \mathrm {INT\_MAX} -b}$ zu verwenden.

Standardisierung

Nach jahrelanger Arbeit wurde schließlich 1998 die endgültige Fassung der Sprache C++ (ISO/IEC 14882:1998) genormt. Diese Version wurde im Nachhinein, als weitere Versionen der Sprache erschienen, auch C++98 genannt. Im Jahr 2003 wurde ISO/IEC 14882:2003 verabschiedet, eine Nachbesserung der Norm von 1998, in der einige Missverständnisse beseitigt und mehrere Details klarer formuliert wurden. Diese Version wird umgangssprachlich auch C++03 genannt.

Verbesserungen am Sprachkern

C++98 deckte einige typische Problemfelder der Programmierung noch nicht ausreichend ab, zum Beispiel die Unterstützung von Nebenläufigkeit (Threads), deren Integration in C++, insbesondere für die Verwendung in Mehrprozessorumgebungen, eine Überarbeitung der Sprache unumgänglich machte. Durch die Einführung eines Speichermodells wurden Garantien der Sprache für den nebenläufigen Betrieb festgelegt, um Mehrdeutigkeiten in der Abarbeitungsreihenfolge sowohl aufzulösen als auch in bestimmten Fällen aufrechtzuerhalten und dadurch Spielraum für Optimierungen zu schaffen.

Zu den weitreichenderen Spracherweiterungen gehörte ferner die automatische Typableitung zur Ableitung von Ergebnistypen aus Ausdrücken und die sogenannten R-Wert-Referenzen, mit deren Hilfe sich als Ergänzung zu dem bereits vorhandenen Kopieren von Objekten dann auch ein Verschieben realisieren lässt, außerdem bereichsbasierte For-Schleifen (foreach) über Container und eingebaute Felder.

Erweiterung der Programmbibliothek

Im April 2006 gab das C++-Standardisierungskomitee den sogenannten ersten Technischen Report (TR1) heraus, eine nicht normative Ergänzung zur aktuell gültigen, 1998 definierten Bibliothek, mit der Erweiterungsvorschläge vor einer möglichen Übernahme in die C++-Standardbibliothek auf ihre Praxistauglichkeit hin untersucht werden sollen. Viele Compiler-Hersteller lieferten den TR1 mit ihren Produkten aus.

Im TR1 waren u. a. reguläre Ausdrücke, verschiedene intelligente Zeiger, ungeordnete assoziative Container, eine Zufallszahlenbibliothek, Hilfsmittel für die C++-Metaprogrammierung, Tupel sowie numerische und mathematische Bibliotheken enthalten. Die meisten dieser Erweiterungen stammten aus der Boost-Bibliothek, woraus sie mit minimalen Änderungen übernommen wurden. Außerdem waren sämtliche Bibliothekserweiterungen der 1999 überarbeiteten Programmiersprache C (C99) in einer an C++ angepassten Form enthalten.

Mit Ausnahme der numerischen und mathematischen Bibliotheken wurden alle TR1-Erweiterungen in die Sprachnorm C++11 übernommen. Ebenfalls wurde eine eigene Bibliothek zur Unterstützung von Threads eingeführt.

C++11

Mit der Norm ISO/IEC 14882:2011, auch bekannt als C++11, wurden viele weitreichende Neuerungen in C++ eingeführt, wie auszugsweise:

• Lambdas (Anonyme Funktionen), welche vor der Verabschiedung des C++11-Standards in anderen Sprachen schon teils breite Anwendung fanden, erweitern die Sprache vor allem im Bereich der funktionalen Programmierung.
• Eine erleichterte Typbehandlung mit Typinferenz ist nun über das Schlüsselwort auto (das nun nicht mehr ein Speicherklassen-Specifier ist) einerseits und das Schlüsselwort decltype (das den Typ eines Ausdrucks statisch zur Compilezeit zurückgibt, sofern ermittelbar) andererseits möglich. Beide Schlüsselworte zeigen ihre Stärke zudem auch im Verbund. So können ganze Funktionen, deren Rückgabetypen beispielsweise nur schwer vom Programmierer einzusehen sind, weil sie beispielsweise innerhalb komplexerer Klassentemplates liegen, komfortabel definiert werden:

  template <typename Factory>
  auto createObject(const Factory& creator) -> decltype(creator.makeObject()) {
      return creator.makeObject();
  }
  

• Streng typisierte enums (enum class) beseitigen Probleme mit Namenskollisionen und schränken die Fehleranfälligkeit in Bezug auf implizite Typkonvertierungen ein.
• Sogenannte „range-based loops“ mittels eines modifizierten for-Statements erleichtern die Arbeit mit Containern und Arrays in der Art, dass Iteratoren beim Traversieren von Objekten dieser Datentypen für viele Anwendungsfälle überflüssig werden:

  #include <iostream>
  #include <string>
  #include <vector>
  
  using namespace std;
  
  void printNames(const vector<string>& names) {
      for (const string& singleName: names)
          cout << singleName << endl;
  }
  

• Es dürfen direkt aufeinanderfolgende spitze Klammern bei Templates benutzt werden: map<int, vector<int>>.
• Überdies erfolgte mit der Einführung von variadischen (vielstelligen) Templates eine großräumige Erweiterung der Nutzungsmöglichkeiten von Templates. Diese ermöglichen nun eine nicht fixe Anzahl von Template-Argumenten template<typename... Values> class VariadicExampleClass;, was weitreichende Optionen und Vereinfachungen im Code- bzw. Algorithmenaufbau und der Codestruktur allgemein ermöglicht. Des Weiteren haben sie, wie viele andere C++11-Erweiterungen auch, das Potential, die Notwendigkeit zur Nutzung von teils fehleranfälligen und nicht robusten Macros weiter einzuschränken.
• Die explizite Nutzbarkeit sogenannter Rvalue-Referenzen ermöglicht, aufbauend unter anderem auf sogenannter Bewegungssemantik, ein breites Spektrum von Codevereinfachungen, Laufzeitoptimierungen und ausnahmesicherer Programmierung. Mit den Rvalue-Referenzen wurden auch die sogenannten universellen Referenzen eingeführt, welche das Problem des „Perfect forwarding“ auf Sprachebene robust und einfach lösbar machen (die konsistente Weiterreichung von Typen innerhalb von Templatekonstrukten, die per „type deduction“ aufgelöst wurden, an weiterführende Templates). Vor der Verabschiedung des C++11-Standards war dies zumindest rein auf Sprachebene nicht möglich und erforderte vom Programmierer je nach Problemfall mehr oder weniger viel Eigenregie mit teils entsprechender Codeaufblähung und -Duplizierung.
• Außerdem wurden einige Features aus C11 übernommen, zum Beispiel Ganzzahlen mit mindestens 64 Bit (long long) oder Zusicherungen zur Übersetzungszeit mittels static_assert (in C11: _Static_assert).

Themen der Sprache C++, die Rechenzeit und Speicherplatz betreffen, wurden im sogenannten technical report ISO/IEC TR 18015:2006 behandelt.

Zum Zeitpunkt der Einführung des Standards und auch noch vergleichsweise lange darüber hinaus unterstützten viele gängige Compiler diesen nicht vollständig bzw. mit Bezug auf einige Erweiterungen mitunter fehlerhaft. Besonders starke Einschränkungen zeigte diesbezüglich zum Beispiel Microsoft mit Visual C++ 2012. Mit Visual C++ 2015 sind mittlerweile jedoch nahezu alle wichtigen größeren Spracherweiterungen berücksichtigt worden.

C++14

C++14, beschrieben im Standard ISO/IEC 14882:2014, erweitert die Einsatzmöglichkeiten von auto und decltype, schwächt die Voraussetzungen für constexpr ab, erlaubt Variablen-Templates zu definieren (beispielsweise um mehrere Versionen von π mit je nach Typ unterschiedlicher Genauigkeit zu definieren), führt Binärliterale ein (0b...), führt Hochkommata als Trennzeichen in Zahlen ein, erlaubt generische Lambdas, erweitert Lambda capture expressions und führt das Attribut deprecated ein.

Außerdem wurde die Standardbibliothek um ein paar Funktionen ergänzt, die bei C++11 „vergessen“ bzw. „übersehen“ wurden (z. B. std::make_unique) und etliche Funktionsdeklarationen nun als constexpr umdeklariert, was dem Compiler aggressivere Optimierungen gestattet.

Während der Entwicklungsphase wurde C++14 auch C++1y genannt, um anzudeuten, dass es die Nachfolgeversion der vormals als C++0x genannten Version sein wird.

C++17

Im März 2017 hat das ISO-C++-Komitee den Sprachstandard C++17 technisch abgeschlossen. Für die neue Fassung wurde unter anderem die Aufnahme des Typen std::byte beschlossen. Dieser ist explizit für den byte-weisen Zugriff auf den Speicher bestimmt. Es wurden neue, generische Container eingeführt: std::any als Alternative zu void* mit Typeüberprüfung zur Laufzeit, std::variant als Alternative zur aus C übernommenen Union mit Laufzeit-Typprüfung und std::optional, ein Container, der genau ein Element enthalten kann, aber nicht muss.

Bis zur offiziellen Verabschiedung wurde die Fassung auch als C++1z bezeichnet.

Nach dem Sommer-Meeting Mitte Juli verriet der C++-Experte Herb Sutter, der für die Einberufung des Komitees verantwortlich ist, in seinem Blog bereits erste Pläne für C++20.

C++20

Die finale Version von C++20 wurde im Dezember 2020 veröffentlicht, nachdem er im Februar finalisiert und im September bestätigt wurde.

• Concepts
• bestimmte Initialisierer (zuerst in C99)
• [=, this] in Lambdas
• Template-Parameter-Listen in Parametern
• Dreiwegevergleich mit dem „spaceship operator“, operator <=>
• Koroutinen
• ein Modulsystem zur Codekapselung und kürzeren Kompilierzeiten
• std::format als moderner Ersatz für sprintf und stringstreams
• std::span Erweiterung des Konzeptes von string_view (C++17) auf beliebige Felder

C++23/26

• Reflection
• Executors
• Pattern Matching
• Networking