virtual inheritance - Default Ctor wird aufgerufen, explizit wird jedoch ein anderer aufgerufen

Sone

Etwas nicht Konstruiertes muss nicht immer eine Adresse haben.

Damit implizierst du, dass der Konstruktor dann für das Objekt selbst Speicher anfordert.
Oder könnte es sein, dass zwar Speicher reserviert ist, aber die Adresse noch nicht feststeht?

Merke: Es geht nicht darum, ob man die Adresse irgendwie im Programm bestimmen und in eine Variable stopfen kann. Es geht lediglich darum, ob die Adresse feststeht, sprich: ob man als Allwissender mit 99%iger* Wahrscheinlichkeit voraussagen kann, Objekt a wird die Adresse x haben.

out schrieb:

Sone schrieb:

Etwas nicht konstruiertes muss aber schon allein deswegen eine Adresse haben, weil vor der Initialisierung eines Objektes durch den Konstruktor dafür Speicher angefordert wird.

Hast du mir die Stelle im Draft? Ich finds net

Hmm. Warten wir bis camper kommt.

*Vielleicht gibt es ja auch einen Stromausfall, kurz bevor der Ctor aufgerufen wird...

Sone schrieb:

Etwas nicht Konstruiertes muss nicht immer eine Adresse haben.

Damit implizierst du, dass der Konstruktor dann für das Objekt selbst Speicher anfordert.
Oder könnte es sein, dass zwar Speicher reserviert ist, aber die Adresse noch nicht feststeht?

Merke: Es geht nicht darum, ob man die Adresse irgendwie im Programm bestimmen und in eine Variable stopfen kann. Es geht lediglich darum, ob die Adresse feststeht, sprich: ob man als Allwissender mit 99%iger* Wahrscheinlichkeit voraussagen kann, Objekt a wird die Adresse x haben.

Hast du überhaupt das von mir zitierte [clas.cdtor] genauer angeschaut? Da steht genau das.

Eine etwas leichtere Kost ist das Example dazu:

[clas.cdtor] schrieb:

struct W { int j; };
struct X : public virtual W { };
struct Y {
  int *p;
  X x;
  Y() : p(&x.j) {    // undefined, x is not yet constructed
    }
};

Sone schrieb:

Etwas nicht konstruiertes muss aber schon allein deswegen eine Adresse haben, weil vor der Initialisierung eines Objektes durch den Konstruktor dafür Speicher angefordert wird.

Ok, habe nun endlich ein paar Stellen im Netz gefunden, die dich bestätigen. :p

http://yosefk.com/c++fqa/ctors.html

That's right - constructors initialize objects. In particular, constructors don't allocate the chunk of memory used for storing the object.

http://stackoverflow.com/questions/3617465/how-are-constructors-and-destructors-implemented-in-c

The constructor is called with this already pointing to the allocated memory; it need just fill in the members at that location.

Jetzt fehlt nur noch die Stelle im Draft

Sone

Hast du überhaupt das von mir zitierte [clas.cdtor] genauer angeschaut?

Ja. Was soll da stehen? Wann der Speicher für ein Objekt angefordert wird? Wohl kaum.

bullshit schrieb:

Eine etwas leichtere Kost ist das Example dazu:

struct W { int j; };
struct X : public virtual W { };
struct Y {
  int *p;
  X x;
  Y() : p(&x.j) {    // undefined, x is not yet constructed
    }
};

Joa, das ist UB. Das haben wir nun geklärt.

Die aktuelle Frage ist gerade, wann wird der Speicher für eine Instanz angefordert und von wem.

Swordfish

...

camper

otze schrieb:

Ich bin mir sicher, dass es einen Weg um die virtuell Vererbung rum gibt.
Ausserdem wäre ich vorsichtig, ob das was du da tust überhaupt funktioniert.

vec ist zu dem Zitpunkt noch nicht konstruiert.

Das ist kein Problem.
Es wird ja nur ein lvalue (this->vec) gebildet, das auf zwar uninitialisierten aber reservierten (3.7.5) Speicher verweist. Die Konstruktion von Example hat begonnen, also kann ein Verweis auf sein Member vec gebildet werden. Und die weitere Verwendung dieses lvalues ist hier unproblematisch (3.8/5, 3.8/6).

Vom Rest der Diskussion kriege ich bloss Kopfschmerzen...

Sone

Well?

Zu viel A Clockwork Orange geguckt?

Swordfish schrieb:

Komische Frage. Wann wird Speicher für
int i;
reserviert? Bei der Deklaration von i durch Bewegen des Stackpointers.

Wieso sollt es für Klasseninstanzen anders sein?

Für Stackobjekte ist es sicherlich so.
Btw: Wird der Stackpointer nicht bei der Definition erhöht/erniedrigt?

Swordfish

...

Auf jeden Fall: Dankeschön!

Sone

Nö, kenn den Film nicht.

Naja. Dieser Anglizismus ist jedenfalls erschreckend.

bar liegt am Heap, new besorgt Speicher, danach def-ctor

Genau.

Der Stackrahmen wird bei Funktionseintritt eingerichtet.

Was meinst du mit "eingerichtet"?

Ich werde dann halt dennoch eine entsprechende set()-Funktion bauen, falls doch irgendwann einmal ein Objekt das nicht auf dem Stack liegt gewrapped werden muss.
Man weiß ja nie

Swordfish

...