Was kommt zuerst: Destruktor oder Deallokation ?

hustbaer

Spaghettimann schrieb:

Wer genau kümmert sich eigentlich um die Speicherverwaltung: Der Compiler oder das OS?!

Kommt auf die Implementierung an. Wieso sollte das aber nen Unterschied machen? Auch das OS kann Dinge im Usermode machen. Ob der Code in einer Library steht die vom OS oder vom Compiler bereitgestellt wird, macht letztlich keinen Unterschied.

Wobei: primär ist natürlich der Compiler bzw. "die Implementierung" zuständig. Nur gibt es eben Implementierungen die in malloc bzw. ::operator new einfach nur sofort an eine OS Funktion weitergeben.

Spaghettimann schrieb:

Wenns der Compiler wäre, würde ich nicht verstehen, warum es als kostspielig angesehen wird.
Aber wenns das OS ist, muss ja für jeden Speicherbereich den ich mir reserviere wieder im Speicher darüber buchgeführt werden... Also "jedes int frisst 2*sizeof(int) Speicher"??

Njjjjjjaaa-nein

Also gut, ja. In gewissen Fällen könnte der Compiler sagen "hier wird genau ein T zerstört, T ist 123 Byte gross, also geb' ich jetzt mal 123 Byte frei".

Aber: es gibt auch Heap-Implementierungen die siche die Grösse zu jeder Allokation selbst "merken", die viele Allokationen (speziell solche mit Grösse = 1, 2, 4, 8 Byte und etliche andere übliche Grössen) ganz ohne Overhead machen können. Weil sie anhand der Adresse des Speichers auf die Grösse des Blocks rückschliessen können.
Ich glaube sogar dass die meisten mainstream OS' mittlerweile mit solchen Heap-Implementierungen ausgeliefert werden.

@ Arcoth: Stimmt schon, dass das in der Regel nicht viel ausmacht. Andererseits wäre das schlechtestenfalls ein Faktor 2, was die Speicherbelegung angeht..
War mir so einfach nicht wirklich bewusst.

Aber da gibts ja das von hustbaer genannte Konzept, was einfach und genial ist.

Also jedenfalls Danke für den Exkurs. Ist zwar oft garnicht relevant, aber trotzdem gut zu wissen, was da unter der Haube tatsächlich vor sich geht.