C++: delete auf Elternklasse

[Bronco (Gast)]

Hallo zusammen,

ich habe eine Elternklasse, von der ich mehrere Kindklassen ableite.
Die Kindklassen haben alle eine unterschiedliche Anzahl an Variablen, 
d.h. ihre Instanzen belegen unterschiedlich viel RAM.
Mein Wunsch ist es, der Einfachheit halber möglichst oft über einen 
Elternklassen-Pointer auf die Instanzen der unterschiedlichen 
Kindklassen zuzugreifen.

Beim Anlegen einer Kindklassen-Instanz muss ich eine 
Einzelfallbehandlung machen:

elternklasse_t* eltklaptr;
if      (kindklassentyp = 0) { eltklaptr = new kindklasse_0_t; }
else if (kindklassentyp = 1) { eltklaptr = new kindklasse_1_t; }
else if (kindklassentyp = 2) { eltklaptr = new kindklasse_2_t; }
...

Dass Freigeben einer Kindklassen-Instanz würde ich gerne 
vereinheitlichen:

delete eltklaptr;

Nun habe ich im Netz folgendes gefunden:
Ist der Destructor der Elternklasse virtuel, wird bei delete mit 
Elternklassenzugriff die komplette Instanz (Elternteil und Kindteil) 
freigegeben.
Ist der Destructor der Elternklasse aber nicht virtuel, wird bei delete 
mit Elternklassenzugriff nur der Elternteil der Instanz freigegeben.

Das würde ja bedeutet, dass der Kindteil der Instanz als Speicherleiche 
zurückbleibt. Ist das richtig?

[Kai S. (zigzeg)]

Nicht ganz. Wahrscheinlich wird durch die Abbildung auf den 
zugrundeliegenden malloc()/free() Mechanismus aller Speicher 
freigegeben.
Problem ist aber das die Destructoren der Daten der Kind-Objekte nicht 
aufgerufen werden. Das kann unterschiedliche Auswirkungen haben - gut 
ist das auf jeden Fall nicht !

[Daniel A. (daniel-a)]

Bronco schrieb:
> if      (kindklassentyp = 0) { eltklaptr = new kindklasse_0_t; }
> else if (kindklassentyp = 1) { eltklaptr = new kindklasse_1_t; }

Vorsicht! der vergleichsoperator ist == und nicht =
Für soetwas würde ich eher arrays oder const std::map nehmen.

template<typename T> 
  T* constructor(){
    return new T();
  }
  typedef base*(*constructor_t)();
  const constructor_t constructors[] = {
    &constructor<derived1>,
    &constructor<derived2>,
    &constructor<derived3>
  };
  const std::size_t constructor_count = sizeof(constructors)/sizeof(constructor_t);
...
  base* eltklaptr = (*constructors[kindklassentyp])();
...

Bronco schrieb:
> Ist der Destructor der Elternklasse aber nicht virtuel, wird bei delete

Das ist undefiniert.

[Oliver S. (oliverso)]

Bronco schrieb:
> Nun habe ich im Netz folgendes gefunden:
> ...

Deine Fundstelle im Netz ist da ungenau. Merk dir einfach anders herum: 
Willst du delete auf abgeleitete Klassen über einen Pointer auf die 
Basisklasse ausführen, muß der Destruktor der Basisklasse virtuell sein.

Einfach machen, und alles wird gut.

[Programmierer (Gast)]

Daniel A. schrieb:
> Vorsicht! der vergleichsoperator ist == und nicht =
> Für soetwas würde ich eher arrays oder const std::map nehmen.
So was nennt sich factory, und so würde ich as auch im Code nennen, und 
nicht "constructor", denn ein C ++ konstruktor ist es nicht! Und statt 
Funktionspointern kann man das mit std::function schöner/universeller 
machen.

[Bronco (Gast)]

Danke für die Antworten:

Was mich verwirrt hatte:

http://stackoverflow.com/questions/461203/when-to-use-virtual-destructors
---------8<---------------
Since Base's destructor is not virtual and b is a Base* pointing to a 
Derived object, delete b has undefined behaviour. In most 
implementations, the call to the destructor will be resolved like any 
non-virtual code, meaning that the destructor of the base class will be 
called but not the one of the derived class, resulting in resources 
leak.
---------8<---------------

Hier wird gesagt, dass das Nicht-Aufrufen des Kindklassen-Destructor zu 
"ressource leak" führt.
Ist logisch für den Fall, wo im Kindklassen-Destructor explizit 
Ressourcen freigegeben werden.
Aber auf den mit new reservierten Speicherplatz für die 
Kindklassen-Instanz, der nun mit delete wieder freigeben wird, hat das 
doch keinen Einfluss, oder?

[Oliver S. (oliverso)]

Programmierer schrieb:
> denn ein C ++ konstruktor ist es nicht!

So ist es. So braucht man ja nicht mal mehr Vererbung.

Aber das ist ja das schöne an C++. Jeder, wie er will. Der eine machts 
old-school, der andere baut Templates.

Oliver

[Rolf M. (rmagnus)]

Bronco schrieb:
> Hier wird gesagt, dass das Nicht-Aufrufen des Kindklassen-Destructor zu
> "ressource leak" führt.

Es wird gesagt, daß nicht definiert ist, was passiert. Das ist der 
wichtige Teil. Als Randnotiz wird noch erwähnt, daß es auf den meisten 
Compilern dazu führen wird, daß nur der Destruktor der Basisklasse 
aufgerufen wird.

> Ist logisch für den Fall, wo im Kindklassen-Destructor explizit
> Ressourcen freigegeben werden.

Es passiert vermutlich auch in dem Fall, indem die Kindklasse wieder 
Objekte mit Destruktoren enthält, die beim Zerstören eines Objekts der 
Kindklasse implizit mit aufgerufen werden.

> Aber auf den mit new reservierten Speicherplatz für die
> Kindklassen-Instanz, der nun mit delete wieder freigeben wird, hat das
> doch keinen Einfluss, oder?

Spielt eigentlich keine Rolle. Wie gesagt: Das wichtige ist, daß das 
Verhalten undefiniert ist und damit erstens vom Compiler (und notfalls 
auch der Mondphase) abhängig sein kann und zweitens grundsätzlich zu 
vermeiden ist.

[Bronco (Gast)]

Rolf Magnus schrieb:
> Es wird gesagt, daß nicht definiert ist, was passiert. Das ist der
> wichtige Teil.

Okay, verstanden.
Dann bin ich aber echt froh, dass der GCC eine Warnung ausgibt, denn von 
allein wäre ich da nicht drauf gekommen.

[Programmierer (Gast)]

Oliver S. schrieb:
> So ist es. So braucht man ja nicht mal mehr Vererbung.
Doch, braucht man wohl. Die Klassen, von denen Instanzen angelegt werden 
sollen, müssen eine gemeinsame Basisklasse haben, die dann als 
Rückgabetyp der Factory-Funktionen verwendet wird. Was willst du als 
Rückgabetyp verwenden, wenn es keine gemeinsame Basisklasse gibt? Und 
wie virtuelle Funktionen aufrufen?

[Oliver S. (oliverso)]

Das ist ja das "schöne" an Templates. Lauter völlig unabhängige Klassen, 
die Zillionen Kombinationsmöglichkeiten verwaltet der Compiler.

Oliver

[Programmierer (Gast)]

Oliver S. schrieb:
> Das ist ja das "schöne" an Templates. Lauter völlig unabhängige Klassen,
> die Zillionen Kombinationsmöglichkeiten verwaltet der Compiler.
Das bringt dir leider bei Factory-Funktionen gar nichts. Gib mir mal ein 
konkretes Code-Beispiel wie du das hier ohne Vererbung hinbekommen 
willst:

https://ideone.com/h2xEbm