Initialisierungsliste im Ctor

Welche Vorteile hat die Initialisierungsliste noch,
abgesehen von der "Initialisierung" statt einer "Definition+Zuweisung" ?

mfg dweb

Dweb schrieb:

Welche Vorteile hat die Initialisierungsliste noch,
abgesehen von der "Initialisierung" statt einer "Definition+Zuweisung" ?

Du kannst Konstanten initialisieren und Konstruktoren von Basisklassen aufrufen.

Janjan schrieb:

Dweb schrieb:

Welche Vorteile hat die Initialisierungsliste noch,
abgesehen von der "Initialisierung" statt einer "Definition+Zuweisung" ?

Du kannst Konstanten initialisieren und Konstruktoren von Basisklassen aufrufen.

ohh joa Konstruktoraufruf der Basisklasse

hmm Initialisierung von Konstanten und Referencen hätte ich jetzt eher unter "have-to" eingeordnet als unter "Vorteil" xD

Dweb schrieb:

ohh joa Konstruktoraufruf der Basisklasse

hmm Initialisierung von Konstanten und Referencen hätte ich jetzt eher unter "have-to" eingeordnet als unter "Vorteil" xD

Die Konstruktoren der Basisklasse kannst du auch nur in der Initialisierungsliste aufrufen. Also auch ein "have-to".

kann ich dir net widersprechen^^

Nexus

Dweb schrieb:

Welche Vorteile hat die Initialisierungsliste noch,
abgesehen von der "Initialisierung" statt einer "Definition+Zuweisung" ?

Konsistenz. Alles in der Initialisierungsliste, dann brauchst du keine Sonderbehandlung für Dinge, die dort stehen müssen und hast keine Nachteile bei optionalen Dingen. Ausnahmen wie verzögerte Initialisierung gibts natürlich trotzdem. Aber als Grundsatz empfiehlt es sich, so viel wie möglich in der Konstruktor-Initialisierungsliste zu initialisieren.

Wofür die Initialisierungsliste zwingend notwendig ist:

const -qualifizierte Membervariablen
Referenzen
Member ohne Defaultkonstruktor
Member, die den Zuweisungsoperator nicht unterstützen
Basisklassen ohne Defaultkonstruktor

hustbaer

Member, die den Zuweisungsoperator nicht unterstützen

Nope. Nicht im geringsten. Also nicht zwingend.

Nexus

Du hast Recht. Ich hätte ausdrücklich sagen sollen, dass ich mich auf den Vergleich von Zuweisungen im Konstruktorrumpf und Initialisierungen in der Initialisierungsliste beziehe.

Also "zwingend" im Sinne von "funktioniert nicht mit späteren Zuweisungen".

hustbaer

OK, wenn du explizit Zuweisung im Konstruktorrumpf schreibst, dann ja.

Ich dachte an Dinge wie CFile aus der MFC.

Kann default-konstruiert werden.
Kann nicht zugewiesen werden.
Kann dafür aber mit diversen Funktionen nachträglich "geändert" (bzw. allgmein verwendet) werden.

z.B. mit Open() ein File aufmachen etc.

Initialisierungslisten werden schnell unleserlich, daher versuche ich sie grundsätzlich zu vermeiden.

Nexus

einint schrieb:

Initialisierungslisten werden schnell unleserlich, daher versuche ich sie grundsätzlich zu vermeiden.

Inwiefern ist

MyClass::MyClass(int newInt, double newDouble, const std::string& newString)
: myInt(newInt)
, myDouble(newDouble)
, myString(newString)
{
}

unübersichtlicher als

MyClass::MyClass(int newInt, double newDouble, const std::string& newString)
{
  myInt = newInt;
  myDouble = newDouble;
  myString = newString;
}

Und wie kann ich mir das vorstellen? Nimmst du die erwähnten Nachteile billigend in Kauf, nur der Syntax wegen?

Oder schlimmer, designst du Klassen sogar entsprechend? Also z.B. überall Defaultkonstruktoren bereitstellen, auch wenn diese unangebracht sind?