Kapitel 11. Removed und Deprecated

In diesem Kapitel:

• „Removed“

• „Deprecated“

Ein wichtiges Design-Ziel von C++11 ist es, abwärtskompatibel zu sein. So verwundert es nicht, das nur wenige Features aus dem alten C++-Standard entfernt bzw. auf deprecated gesetzt wurden.

Removed

auto

Durch auto int a= 5; wurde in C++98 die Variable a auf dem Stack angelegt. Das Schlüsselwort auto ist redundant, da das Anlegen einer Variablen auf dem Stack automatisch geschieht. Dies ist der Grund dafür, dass auto sehr selten verwendet wurde. In C++11 deklariert auto eine Variable, die ihren Typ durch Typableitung automatisch erhält:

auto a=5;

export

Das Schlüsselwort export wurde aus C++11 entfernt. Die Idee von export war es, dass nur die Deklaration und nicht die Definition eines Templates an der Stelle ihrer Anwendung bekannt sein muss. Sieht man von dem Comeau-Compiler (Comeau.Computing, 2008) ab, hat dieses Feature kein Compiler-Hersteller umgesetzt. Da ist es sehr pragmatisch, es wieder aus dem neuen Standard zu entfernen.

Deprecated

register

Mit dem Schlüsselwort register ließ sich in C++98 spezifizieren, dass die Variable a in der Anweisung register int a; in einem Prozessorregister angelegt werden soll. Dies war nur eine Empfehlung an den Prozessor, um häufige Zugriffe auf die Variable möglichst schnell auszuführen.

Ausnahmespezifikation

Ausnahmespezifikationen sind in C++11 auch deprecated. Die Ausnahmespezifikation einer Funktion gibt an, welche Ausnahmen die Funktion auslösen kann. Worin die Probleme von Ausnahmespezifikationen bestehen und warum sie in C++ nicht verwendet werden sollen, lässt sich schön in Herb Sutters Artikel »A Pragmatic Look at Exception Specifications« (Sutter, 2002) nachlesen.

Praxistipp

Verwenden Sie keine Ausnahmespezifikationen.

Herb Sutter fasst die Erfahrung der letzten Jahre mit Ausnahmespezifikationen in zwei Ratschlägen zusammen.

Moral #1: Never write an exception specification.

Moral #2: Except possibly an empty one, but if I were you I’d avoid even that.

Die Moral von der Geschichte ist schnell paraphrasiert:

Verwenden Sie keine Ausnahmespezifikationen.

Exkurs: noexcept

Die Geschichte der Ausnahmen ist in C++11 noch nicht zu Ende. Relativ spät wurde in C++11 das neue Schlüsselwort noexcept aufgenommen. Damit lässt sich in C++11 eine Funktion auszeichnen, für die eine der beiden Bedingungen gelten soll:

1. Die Funktion wird keine Ausnahmen werfen.

2. Das Programm kann auf eine Ausnahme, die durch diese Funktion geworfen wird, nicht reagieren. In diesem Fall wird direkt std::terminate aufgerufen.

Im Gegensatz zur Ausnahmespezifikation throw wird das Schlüsselwort noexcept zur Übersetzungszeit ausgewertet. Die Idee ist, dass dem Compiler durch die Zusicherung mit noexcept weitere Optionen zur Optimierung offenstehen.

Dies ist der Grund dafür, dass das Schlüsselwort noexcept verbreitet und einheitlich in der Standard Template Library verwendet wird, um die Performance zu verbessern und die Anforderungen explizit herauszustellen: »noexcept is widely and systematically used in the standard library to improve performance and clarify requirements.« (Stroustrup, 2011)

Die Implementierung des neuen Smart Pointer std::unique_ptr ist ein typisches Beispiel für den Einsatz von noexcept.

constexpr unique_ptr() noexcept;
explicit unique_ptr(pointer p) noexcept;
unique_ptr(pointer p, see below d1) noexcept;
unique_ptr(pointer p, see below d2) noexcept;
unique_ptr(unique_ptr&& u) noexcept;
constexpr unique_ptr(nullptr_t) : unique_ptr() { }
template <class U, class E>
unique_ptr(unique_ptr<U, E>&& u) noexcept;
template <class U>
unique_ptr(auto_ptr<U>&& u) noexcept;

Listing 11.1 noexcept-Schlüsselwort in den Konstruktoren von std::unique_ptr

auto_ptr, bind1st und bind2nd

Der Vollständigkeit halber seien hier noch std::auto_ptr sowie std::bind1st und std::bind2nd erwähnt, die ebenfalls mit C++11 deprecated sind. Während der Smart Pointer std::auto_ptr durch std::unique_ptr ersetzt wird, bietet std::bind, indem er eine Funktion und ihre Argumente bindet, die Funktionalität von std::bind1std und std::bind2nd deutlich komfortabler an. Insbesondere std::unique_ptr und std::bind werden in Teil IV, noch ausführlich erläutert.