C++ Polymorphismus und Speichermanagement

[anakin87]

Hallo,
ich beschäftige mich gerade mit C++, Polymorphismus und dem Speichermanagement. Da ich aus der C#-Ecke komme und die Speicherverwaltung ungewohnt finde, wollte ich einen kleinen Helper basteln der sich für mich darum kümmert.


//kurzum:
//Klasse Fahrzeug (Base)
//Klasse Auto erbt von Fahrzeug

std::list<Fahrzeug*> fList; //sammle alle Objekte um sie am Ende freizugeben

//für jedes Objekt
fList.push_back(fahrzeugObjekt);

//oder auch
fList.push_back(autoObjekt);

for(Fahrzeug* item:flist)
{delete item;}



So laut Polymorphismus kann ich auch Auto* in die Liste speichern. Nur sizeof(fahrzeug) ist 12 und sizeof(auto) ist 44; kann das Programm dann den Speicher richtig freigeben wenn er alle Auto* Objekte als Fahrzeug* behandelt?

Den einzigen Unterschied den ich eben feststellen konnte ist, dass dann nur der Fahrzeug-Destructor aufgerufen wird, was ja klar ist, da ja in der Liste alles (Fahrzeug*) ist.
Aber ich würde gerne wissen ob er dann 44 Byte oder 12 freigibt? Weil woher weis er dann wie groß das Objekt wirklicht ist....

Beste Grüße

[del_4901]

Den einzigen Unterschied den ich eben feststellen konnte ist, dass dann nur der Fahrzeug-Destructor aufgerufen wird, was ja klar ist, da ja in der Liste alles (Fahrzeug*) ist.

Dafuer gibt es virtuelle Destruktoren.

Aber ich würde gerne wissen ob er dann 44 Byte oder 12 freigibt? Weil woher weis er dann wie groß das Objekt wirklicht ist....
Freigegeben wird immer alles, der Heap speichert sich intern die Groesse.

[anakin87]

Dafuer gibt es virtuelle Destruktoren.

Hm, soweit bin ich im Buch noch nicht, muss ich mir dann gleich mal ansehen.
Manuell sollte auch "((Auto*) object) delete;" mir den Destructor von Auto aufrufen...


Freigegeben wird immer alles, der Heap speichert sich intern die Groesse.

Sehr gut, dann muss ich mich nicht darum kümmen.
Aber der Prozess übergibt dem OS dann nicht immer den gesamten freigemachten Speicher oder? Cached der Prozess noch bevor er alles freigibt?
Weil irgendwie belegt das Programm dach dem delete zu viel Speicher.
Hab es grade mit 2M Objekten getestet und ca. 70% sind freigegeben worden (laut Taskmanager).

mfg

[Ectoplasma]

Aber der Prozess übergibt dem OS dann nicht immer den gesamten freigemachten Speicher oder? Cached der Prozess noch bevor er alles freigibt?
Weil irgendwie belegt das Programm dach dem delete zu viel Speicher.
Hab es grade mit 2M Objekten getestet und ca. 70% sind freigegeben worden (laut Taskmanager).

mfg

Die C-Runtime hat seine eigene Speicherverwaltung. Kleine Speicherblöcke werden nicht sofort an das OS zurückgegeben. Alloziere mal zum Spass 100MB und gebe sie dann wieder frei. Blöcke dieser Größe werden sofort an das OS zurückgegeben.

Kleine Änderung an deinem Code (kommt wahrscheinlich noch in deinem Buch):

//kurzum:
//Klasse Fahrzeug (Base)
//Klasse Auto erbt von Fahrzeug

#include <tr1/memory>

std::list< std::tr1::shared_ptr<Fahrzeug> > fList; //sammle alle Objekte um sie am Ende freizugeben

//für jedes Objekt
fList.push_back(fahrzeugObjekt);

//oder auch
fList.push_back(autoObjekt);

/* Freigabe nicht mehr nötig, geschieht automatisch durch den shared_ptr
for(Fahrzeug* item:flist)
{delete item;}
*/

[del_4901]

Manuell sollte auch "((Auto*) object) delete;" mir den Destructor von Auto aufrufen...
Sehr gut, dann muss ich mich nicht darum kümmen.
Wenn du das bei mir einchecken wuerdest, dann gaebe es 5min spaeter nen deftigen Schlag in Genick. Gewoehn dir also lieber gleich virtuelle Destrutoren an wenn du mit hetherogenen Containern arbeitest. Alles andere ist Pfusch.

[anakin87]

*Autsch* -> Schlag erhalten :D
Ja ich gebe zu es ist keine schöne Lösung, an prof. Entwickeln muss ich mich erst gewöhnen.

@Ectoplasma, Smarte Pointer oder? Hm ist c++11 Stuff, da bin ich vorsichtig - weil VistualStudio 2012 kann damit noch nicht so gut (Smartpointer sollten aber funktionieren). Kdevelop also eher gcc (privat) umsobesser ;)

(y) thx an euch 2