Effektiv C++

- Von C zu C++
Bevorzugen sie const und inline gegenüber #define
Bevorzugen sie  gegenüber 
Bevorzugen sie new und delete gegenüber malloc und free
Keine Makros verwenden (templates usw. stattessen)
Variabeldefinitionen möglichst lang aufschieben

- Mit C++ Vertraut machen (2006)
Betrachten Sie C*+ als eine Kombination von Sprachen
Nach Möglichkeit immer const verwenden
Logische (und nicht Bitweise) Konstanz anstreben
Initialisieren von Objekten bevor sie verwendet werden

- Speicherverwaltung
Benutzen Sie korrespondierende Freigabe
 (new<->delete, new[]<->delete[], malloc<->free)
Zeiger Datenelemente im Destruktor delete aufrufen
 out-of-memory Situationen nicht ignorieren

- Konstrukturen, Destruktoren und Zuweisungsoperatoren
Deklarieren Sie einen Copy Konstruktor und einen Zuweisungsoperator
 für Klassen mit dynamisch allozierten Speicher
Bevorzugen sie Initialisierung gegenüber Zuweisung im Konstruktor
Führen sie die Datenelemente in der Reihenfolge ihrer Deklaration auf
Eine virtuelle Funktion bedingt virtuellen Destruktor
operator= eine Referenz auf *this zurückliefern
Allen Datenelementen im operator= etwas zuweisen
Zuweisung auf sich selbst überprüfen (operator=)

- Konstrukturen, Destruktoren und Zuweisungsoperatoren (2006)
Default Konstruktoren,... verstehen
Default -||- unterdrücken wenn unerwünscht
Destruktoren müssen virtuell sein in polymorphen Klassen
Ausnahmen dürfen keine Destruktoren überschreiten
Während Konstruktion und Destruktion keine virtuelle Methoden aufrufen
Selbstzuweisung in operator= beachten

- Resourcenverwaltung (2006)
Verwenden Sie Objekte (RAII)
Kopierverhalten bedenken (auto_ptr vs. shared_ptr)
Neu allokierte Resourcen nur in auto_ptr (o.ä.) zurückgeben

- Entwurf und Deklaration
Streben sie nach vollständigen und minimalen Schnittstellen
Datenelemente in public schnittstelle vermeiden
getter/setter vermeiden
Benutzen von const wann immer möglich
Parameterübergabe via Referenz bevorzugen
Keine Referenzen zurückgeben bei Objekten
Verbieten Sie implizit generierte Elementfunktionen die sie
 gar nicht wünschen (operator= bei arrays)
Unterteilen sie den globalen Namensraum

- Design und Deklaration (2006)
Erleichtern von korrekter Anwendung der Schnittstelle
Erschweren von falscher Anwendung der Schnittstelle
Klassendesign als Typdesign behandeln
Nicht vergessen ausnahmefreie swap Funktion zu unterstützen

- Klassen und Funktionen
keine Handels auf interne Daten zurückliefern
keine nicht konstanten Zeiger oder Referenzen auf stärker
 zugriffsbeschränkte Elemente zurückgeben

- Vererbung
Sorgen Sie dafür, daß öffentliche Vererbung "ist ein" bedeutet.
Unterscheiden Sie zwischen der Vererbung von Schnittstellen und
 von Implementationen
keine nicht-virtuellen Funktionen überschreiben
keinen Defaultparameter redefinieren
Downcasting vermeiden

- Vererbung und objektorientiertes Design (2006)
public-Vererbung soll immer eine "ist-ein" Beziehung modellieren
Keine geerbten Namen verdecken
private-Vererbung soll eine Vererbung der Implementation sein
Nicht-Virtuelle Funktionen dürfen nicht neu definiert werden