Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

TigerClaw25

unregistriert

1

26.03.2013, 16:54

Frage zu Listing 11.3 - Memberinitialisierung im Konstruktor

Hallo Zusammen,

habe wieder einmal ein Verständnisproblem. Diesmal betrifft es Listing 11.3. Ich habe ja die Klasse CPilot und die Klasse CRaumschiff. In CRaumschiff habe ich ja zwei Instanzen der Klasse CPilot.

Dass das nichts mit Vererbung zutun hat, ist mir bereits klar.

Meine Frage jetzt: Wenn ich in der main mit CRaumschiff Jaeger einen Jäaeger erzeuge, wird ja der Konstruktor CRaumschiff(); aufgerufen. Wird dann automatisch auch der Konstruktor der Klasse CPilot aufgerufen? Oder passiert das erst, wenn ich über den CRaumschiff-Konstruktor - wie auch im Listing 11.3 gezeigt - die Initialisierung der Membervariablen (damit sind jetzt die beiden INstanzen der Klasse CRaumschiff gemeint) durchführe?

TigerClaw25

unregistriert

2

26.03.2013, 17:41

Hat sich eigentlich von selbst erledigt. Wenn eine Instanz in der main erzeugt wird und diese Klasse selbst auch noch mal Instanzen einer anderen Klasse besitzt, dann werden alle Konstruktoren aufgerufen, da ja bei der Erzeugung einer Instanz automatische auch die Initialisierung der Membervariablen und so weiter stattfindet :)

Trotzdem verstehe ich in Listing 11.3 bei der Initialisierungslisten und Konstanten nicht, weshalb dies wie folgt stattfindet:_

CRaumschiff::CRaumschiff(const string &sKennung):
m_sKennung(sKennung)
....
...
...
Hätte man nicht direkt in der Main den Namen per String an den Konstruktor übergeben können und statdessen schreiben:
CRaumschiff::CRaumschiff(const string &sKennung)
{
m_sKennung = sKennung;
}

Ist doch dasselbe ...

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »TigerClaw25« (26.03.2013, 17:57)


TGGC

1x Rätselkönig

Beiträge: 1 799

Beruf: Software Entwickler

  • Private Nachricht senden

3

26.03.2013, 18:08

Nein, ist eben nicht das gleiche, ganz simpel:

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
class A
{
    B m_O1;
    C* m_pO2;

    A():
    m_O1(10) //hier _irgendwo_ wird der Konstruktor von B fuer m_O1 aufgerufen
    {
        m_pO2= new C;// genau hier wird der Konstruktor von C fuer m_pO2 aufgerufen
    }

};
Das Problem mit _irgendwo_ bekommt man natuerlich zu spueren, sobald die Initialisierung der Member voneinander abhaengig ist. Dann muss man bei der Deklaration aufpassen, da man nichtmal mit einer Initialisirungsliste die Reihenfolge beeinflussen kann.

4

26.03.2013, 18:35

Member werden in der Reihenfolge ihrer Deklaration initialisiert und nicht in der Reihenfolge, in der sie in der Initialisierungsliste stehen. Dass hat den einfach Grund, dass C++ garantiert, dass Objekte in umgekehrter Reihenfolge wieder zerstört sind - und der Destruktor kann nicht wissen über welchen Konstruktor das Objekt erstellt wurde, und verschiedene Konstruktoren könnten verschiedene Initialisierungslisten mit unterschiedlicher Reihenfolge haben - die Deklarationsreihenfolge ist aber eindeutig.

Ein wesentlicher Unterschied in deinem Code ist, dass einmal ein Objekt initialisiert und einmal zugewiesen wird. Taucht ein Memberobjekt in der Initialisierungliste nicht auf, wird sein Standardkonstruktor aufgerufen. Später, bei der Zuweisung im Konstruktorrumpf wird dann der Zuweisungsoperator benutzt um dem Objekt einen neuen Wert zu geben, nachdem es mit den Standardwerten initialisiert wurde. So gesehen wird dabei also das Objekt 2 mal 'initialisiert'.
Sehr wichtig ist die Initialisierungsliste aber bei Objekten, die keinen Standardkonstruktor haben - diese müssen dann in der I.L. auftauchen, oder du bekommst Compilerfehler.
Lieber dumm fragen, als dumm bleiben!

Werbeanzeige