Initialisierungen hinter dem Konstruktor - was soll das hier?

spjoe

es is weder schneller noch langsamer, aber du brauchst diese art der initalisiereung flass du const atrributte hast. Ich meine du kannst const attribute nur hier initialisieren. Sonst oft verwendet bei der Vererbung. Der rest ist eine Frage des codestyles

mfg

Ringding

spjoe schrieb:

aber du brauchst diese art der initalisiereung flass du const atrributte hast.

Referenzen fallen auch darunter...

ness

Naja, aber eigentlich dürfte Initialisierung der Art:

class test
{
private:
    big_and_slwo_to_create_or_change bastcorj;
public:
    test(unsigned bastcorj_arg):bastcorj(bastcorj_arg){};
}

Schneller sein als

class test
{
private:
    big_and_slwo_to_create_or_change bastcorj;
public:
    test(unsigned bastcorj_arg){bastcorj=bastcorj_arg;};
}

Denn beim ersten wird bastcorj mit dem Konstruktor initialisiert, beim 2. mal zwar auch, aber später wieder verändert - redundant...

es kann durchaus schneller sein.

CarstenJ

spjoe schrieb:

es is weder schneller noch langsamer, aber du brauchst diese art der initalisiereung flass du const atrributte hast. Ich meine du kannst const attribute nur hier initialisieren. Sonst oft verwendet bei der Vererbung. Der rest ist eine Frage des codestyles

mfg

Das stimmt so nicht. Wenn du Variablen im Konstruktor statt in der Initialisierungsliste einen Wert zuweist, kann das u. U. ineffizienter sein, da zwei Memberfunktionen aufgerufen werden: Einmal der Defaultkonstruktor und einmal der Zuweisungsoperator.

Meyers: Effektiv C++, Lektion 12: Bevorzugen Sie Initialisierung gegenüber Zuweisung im Konstruktor

Ringding

Das ist durchaus richtig, aber das sollte eh jedem klar sein, zumal hier komplett verschiedene Funktionen aufgerufen werden.

CarstenJ

Ringding schrieb:

Das ist durchaus richtig, aber das sollte eh jedem klar sein, zumal hier komplett verschiedene Funktionen aufgerufen werden.

Aufgrund der Aussagen scheint das ja nicht so klar gewesen zu sein....

spjoe

CarstenJ schrieb:

spjoe schrieb:

es is weder schneller noch langsamer, aber du brauchst diese art der initalisiereung flass du const atrributte hast. Ich meine du kannst const attribute nur hier initialisieren. Sonst oft verwendet bei der Vererbung. Der rest ist eine Frage des codestyles

mfg

Das stimmt so nicht. Wenn du Variablen im Konstruktor statt in der Initialisierungsliste einen Wert zuweist, kann das u. U. ineffizienter sein, da zwei Memberfunktionen aufgerufen werden: Einmal der Defaultkonstruktor und einmal der Zuweisungsoperator.

Meyers: Effektiv C++, Lektion 12: Bevorzugen Sie Initialisierung gegenüber Zuweisung im Konstruktor

Es ist aber auch nicht verboten den Defaultkonstruktor im Konstruktor zu verwenden
muss ja nicht

k{
   var = 12312;
//kann auch
   var(23432);
}

verwenden

mfg

DDR-RAM

das mit dem schneller gilt auf jeden fall schonmal nicht für built-in typen.
und bei trivialen klassen auch nicht, wenn sie inline-funktions-erweiterung möglich ist. Allerdings sollte man, falls nen Konstruktor vorhanden ist, den in der Initialisierungslist auch nutzen.

MfG
DDR-RAM

CarstenJ

spjoe schrieb:

CarstenJ schrieb:

spjoe schrieb:

es is weder schneller noch langsamer, aber du brauchst diese art der initalisiereung flass du const atrributte hast. Ich meine du kannst const attribute nur hier initialisieren. Sonst oft verwendet bei der Vererbung. Der rest ist eine Frage des codestyles

mfg

Das stimmt so nicht. Wenn du Variablen im Konstruktor statt in der Initialisierungsliste einen Wert zuweist, kann das u. U. ineffizienter sein, da zwei Memberfunktionen aufgerufen werden: Einmal der Defaultkonstruktor und einmal der Zuweisungsoperator.

Meyers: Effektiv C++, Lektion 12: Bevorzugen Sie Initialisierung gegenüber Zuweisung im Konstruktor

Es ist aber auch nicht verboten den Defaultkonstruktor im Konstruktor zu verwenden
muss ja nicht
k{
   var = 12312;
//kann auch
   var(23432);
}
verwenden

mfg

Verboten ist wenig in C++, aber ich verstehe jetzt den Zusammenhang nicht?!

Ringding

Er meinte, wenn man

typ a = 123;

schreibt, darf der Compiler das zu

typ a(123);

umbauen. Das geht aber in dem Beispiel mit der Initialisierungsliste nicht.

finix

explicit?

davie

spjoe schrieb:

Es ist aber auch nicht verboten den Defaultkonstruktor im Konstruktor zu verwenden
muss ja nicht
k{
   var = 12312;
//kann auch
   var(23432);
}
verwenden

var ist zu dem zeitpunkt ja schon längst konstruiert. nochmal den konstruktor aufrufen ist da nicht so einfach.
etwas ausformuliert kommt dein beispiel bei mir so an:

struct foo
{
   string x;
   foo () 
   {
      x("bar"); //ruft string::string(const char*) auf  [1]
   }
};

ich hoffe, dir ist klar, dass das nicht stimmt.
zu zeitpunkt [1] ist x schon default-konstruiert worden. hier würde nurnoch eine zuweisung funktionieren. und diese zuweisung wäre auch wirklich eine zuweisung und keine initialisierung.

Ringding schrieb:

Er meinte, wenn man
typ a = 123;
schreibt, darf der Compiler das zu
typ a(123);
umbauen. Das geht aber in dem Beispiel mit der Initialisierungsliste nicht.

wenn er das wirklich meinte, hat das nichts mehr mit membervariablen zu tun gehabt. sehr unsinnig das ganze.
btw. der compiler darf das auch nur dann "umbauen", wenn der copy-ctor von typ public ist. in wirklichkeit ist typ a = 123; ja eine copy-initialization.

finix schrieb:

explicit?

kann dieses "umbauen" geschickt eingesetzt verhindern. das hat mit dem ursprünglichen thema (elementinitialisierungsliste) aber kaum mehr was zu tun.

groovemaster

ayman schrieb:

Fragen
1. Welchen Sinn macht es im obigen Beispiel die ganzen Membervariablen von ISceneNode hinter dem Doppelpunkt zu initialisieren, was immerhin ziemlich unübersichtlich ist (zumal das alles in wenige Zeilen gepackt wurde), anstelle es am Anfang des Konstruktor-Bodies zu machen.

Ich hoffe, dir ist mittlerweile klargeworden, dass die Initialisierungsliste ihren Sinn hat. Zumal du nur mit dieser zB Basisklassen initialisieren kannst. Wenn es dir zu unübersichtlich ist, dann hier mal das Beispiel, wie ich sowas mache

ISceneNode(ISceneNode* parent, ISceneManager* mgr, s32 id=-1,
    const core::vector3df& position = core::vector3df(0,0,0),
    const core::vector3df& rotation = core::vector3df(0,0,0),
    const core::vector3df& scale = core::vector3df(1.0f, 1.0f, 1.0f))
    : IsVisible(true)
    , ID(id)
    , Parent(parent)
    , SceneManager(mgr)
    , AutomaticCullingEnabled(true)
    , DebugDataVisible(false)
    , TriangleSelector(0)
    , RelativeTranslation(position)
    , RelativeRotation(rotation)
    , RelativeScale(scale)
{
    // bla
}

So wird das schon um einiges übersichtlicher.

ayman

Ich wollte mich nur bei Euch für die umfassende Diskussion bedanken. Jetzt ist mir der Fall klar

Grüße
Ayman