Der GCC hat nun eine C++-Implementierung für alle drei Compilerphasen.
Da lohnt es sich mal einen Blick darauf zu werfen, was Gnu von C++ alles nutzen möchte. C++ ist nunmal eine große Sprache und man muss sich in einem Projekt entscheiden, was man davon nutzen will.
Ich fasse mal ganz knapp die Wiki-Seite zusammen. Diese Konventionen haben aber noch recht wenig mit C++11 zu tun, weil „der aktuelle GCC sich immer mit der vorigen (stabilen) Version bauen lassen muss“.

Allgemeine und Dialekt-Regeln

  • Der Code muss sowohl C++03 als auch C++11 konform sein.
    Das liegt natürlich daran, dass eine vorige Version den neuen Compiler übersetzen können muss. In einem eigenen Projekt müsste man diese Regel nicht unbedingt verwenden.
  • Kein RTTI und somit kein dynamic_cast und keine dynamischen Exceptionsspezifikationen throw(...)
  • und (tadaaa:) keine Exceptions! Warum, das wird auch erwähnt: Im Moment ist der Großteil des GCC-Codes nicht Exception-Safe. Dass es gut wäre, den Code auf RAII umzustellen, wird aber auch erwähnt. Das ist jedoch extrem viel Aufwand. Dann wären Exceptions natürlich nötig.
  • Statt auto_ptr nur tr1::shared_ptr, denn ersterer sei defekt. Wenn man sich selbst für C++11 entscheidet, dann kann man wohl auch den C++11 shared_ptr verwenden.

Welche Features?

  • Keine neuen Templates einführen.
  • Keine usings und keine Nested Namespaces.
  • Statt Konversions-Operatoren immer explizite Methoden verwenden. Also statt operator int() besser int getInt().
  • Konstruktoren mit einem Argument sollten immer explicit sein. Auch dies vermeidet überraschende Konvertierungen.
  • Keine Mehrfachvererbung.
  • Copy- und Assignment-Operatoren sollten vermieden werden, sind aber o.k. für pure Werteklassen. Der Grund ist, dass der Compiler selbst brauchbare Versionen generiert, wenn die Klasse keine Pointer enthält. Und wenn sie das tut, dann soll man sicherheitshalber Copy und Assign verbieten. Das führt langfristig dazu, dass Entwickler weniger Raw-Pointer verwenden werden.

C++ Konventionen

  • class und struct sind konzeptionell zu unterscheiden.
  • Konstruktoren sollen alle Datenfelder in ihrer Initialisierungsliste setzen.
  • Alle Datenfelder von Klassen sind private.
  • Namen von Datenfeldern sollten mit einem „_“ enden, also zum Beispiel data_.
  • Methoden sollten diese Datefelder dann mit this verwenden, also zum Beispiel this->data_ (oder natürlich dem Getter).

Das kann als Anregung für eigene Konventionen dienen.