Absturz bei Klassentemplates

unskilled

tippgeber schrieb:

wobei ich mir bei letzerem nicht sicher bin in welcher reihenfolge das initialisisert wird

von links nach rechts bzw oben nach unten, wenn man auf je eine zeile schreibt...

foo::foo()
: a(0),
  b(a)
{}

das ist also iO

bb

drakon

unskilled schrieb:

tippgeber schrieb:

wobei ich mir bei letzerem nicht sicher bin in welcher reihenfolge das initialisisert wird

von links nach rechts bzw oben nach unten, wenn man auf je eine zeile schreibt...
foo::foo()
: a(0),
  b(a)
{}
das ist also iO

bb

Nope. Es spielt keine Rolle, in welcher Reihenfolge das in der Initialisierungsliste steht, sondern in der Deklaration in der Klasse. (das sieht man oft ganz fiese Fehler erzeugen. ;))

unskilled

drakon schrieb:

unskilled schrieb:
tippgeber schrieb:

wobei ich mir bei letzerem nicht sicher bin in welcher reihenfolge das initialisisert wird

von links nach rechts bzw oben nach unten, wenn man auf je eine zeile schreibt...
foo::foo()
: a(0),
  b(a)
{}
das ist also iO

bb
Nope. Es spielt keine Rolle, in welcher Reihenfolge das in der Initialisierungsliste steht, sondern in der Deklaration in der Klasse. (das sieht man oft ganz fiese Fehler erzeugen. ;))

OO
Sicher? Was sollte das für nen Grund haben?
Hab auch gerad nix im Standard dazu gefunden -.-

bb

drakon

ISO/IEC 14882 12.6.2/5 schrieb:

5 Initialization shall proceed in the following order:
[...]
— Then, nonstatic data members shall be initialized in the order they were declared in the class definition
(again regardless of the order of the mem-initializers).

unskilled

danke

Hat das nenn Sinn, dass die das so unlogisch gemacht haben?

pumuckl

oho schrieb:

Hat das nenn Sinn, dass die das so unlogisch gemacht haben?

Das hat einen Sinn, und das ist alles andere als unlogisch. Gesetzt den Fall, die Reihenfolge in der Initialisierungsliste wäre entscheidend. Dann könnte man zwei Konstruktoren haben mit verschiedener Initialisierungsreihenfolge. Beim Zerstören eines Objektes sollte aber die Reihenfolge der Zerstörung der Member umgekehrt zur Initialisierung sein. Je nachdem welcher Konstruktor aufgerufen wurde, müsste also im Destruktor ein anderer Ablauf erfolgen. Dazu müsste wiederum für jedes einzelne Objekt mitgeloggt werden, in welcher Reihenfolge die einzelnen Member initialisiert wurden. Das würde einen nicht akzeptablen Overhead erzeugen.
Bei der Initialisierung in der Reihenfolge der Memberdeklaration kommt dagegen noch ein anderer Vorteil hinzu: Meistens werden die einzelnen Member in der Reihenfolge der Deklaration im Speicher abgelegt. Beim Initialisieren in derselben Reihenfolge kann dann der zum Objekt gehörige Speicher "von vorne nach hinten" initialisiert werden, ohne dass wild darin hin- und hergehüpft werden muss.

noch n punkt, warum es gut ist dass man mit dem neuen standard etwas von diesen initialisierungslisten weg kommt.

unskilled

pumuckl schrieb:

Beim Zerstören eines Objektes sollte aber die Reihenfolge der Zerstörung der Member umgekehrt zur Initialisierung sein.

Wieso muss das der Fall sein?

@1punkt:
aber wenn die Initialisierung der einzelnen Member voneinander abhängig ist, siehts auch schon nich mehr so gut aus mit der neuen Art der Initialisierung - und man ist wieder(immernoch) auf die Init-Liste angewiesen... Abhängig nacheinander klingt nämlich auch immer nach abhängig von Parametern...

bb

drakon

unskilled schrieb:

pumuckl schrieb:

Beim Zerstören eines Objektes sollte aber die Reihenfolge der Zerstörung der Member umgekehrt zur Initialisierung sein.

Wieso muss das der Fall sein?

Ich denke mal, dass dir ein wenig Code mehr sagt, als ein langer Text.

class B
{
public:
	int i;

	B ()
		:
	i ( 2 )
	{}

	~B ()
	{
		i = 0;
	}

};

class A
{
	B& b_;
public:
	A ( B& b )
		:
	b_ ( b )
	{
		std::cout << b_.i << std::endl;
	}

	~A ()
	{
		std::cout << b_.i << std::endl;
	}
};

class foo 
{
	B b;
	A a;

public:
	foo ()
		:
	a ( b )
	{
	}

	~foo ()
	{
	}
};

int main ()
{
	foo f;
}

Was wäre hier, wenn a und b in foo nicht in umgekehrter Reihenfolge zerstört werden würde?

unskilled schrieb:

@1punkt:
aber wenn die Initialisierung der einzelnen Member voneinander abhängig ist, siehts auch schon nich mehr so gut aus mit der neuen Art der Initialisierung - und man ist wieder(immernoch) auf die Init-Liste angewiesen... Abhängig nacheinander klingt nämlich auch immer nach abhängig von Parametern...

Versteh nicht was du meinst. Die InitListe bringt doch nichts bei Abhängigkeiten, da sowieso nach Deklarationsreihen folge init. wird. Oder hab ich drakon falsch verstanden?

drakon

Ich denke er meinte, das, wenn man das machen will, was ich im obigen Beispiel gemacht habe und man zuerst a ( b ) und dann b () macht. Dann sieht das verwirrend aus und kann eine falsche Annahme verursachen.