spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Nein, wird er nicht.

Es ist nichts anderes als ein memset((Destination),0,(Length))

Das hängt davon ab wie du den Speicher allokiert hast...
new -> delete
std::malloc, std::calloc, std::realloc -> std::free
VirtualAlloc -> VirtualFree
HeapAlloc -> HeapFree
...

Das OS räumt die Speicherseiten schneller auf als du mit free/delete hinkriegst. Leaken von application lifetime memory Blöcken, solange sie keine sensitiven Informationen enthalten, ist absolut okay. Sensitive Sachen mit eben dingen wie SecureZeroMemory() ausleeren.

Zitat

Das OS räumt die Speicherseiten schneller auf als du mit free/delete hinkriegst.

Aber eben nur beim Beenden. Außerdem ist es kein guter Stil. Damit hast du ein Speicherleck.

Das meint er nicht. Er meint, dass du mit free()/delete einen Memorybereich zwar wieder für andere Anwendungen freigibst, deine Daten aber noch drinstehen. Bei sensitiven Daten sollte man den Speicher deswegen vorher mit Ramsch-/Nullbytes füllen.

Ich fasse

Zitat

Ich will sichergehen, dass die Bereichen nach Programmende auch frei sind.

So auf als das er leaks vermeiden möchte, nicht das sie sicher überschrieben sind.

Beim beenden muss man Speicher nicht freigeben, Stil hin oder her, Tatsache ist das es das beenden nur langsamer macht wenn man ne Menge Speicher haarklein hinter sich aufräumt. Siehe Firefox. Das OS ist einfach schneller darin die Speicherseiten wieder rauszuwerfen und es nicht bad practice Speicher der sowieso die ganze Applikation über lebt einfach nicht frei zu geben.

Wenn er sicher gehen will das der Speicher mit 0 voll ist beim beenden, SecureZeroMemory(), da ZeroMemory() vom compiler weg optimiert werden kann (genauso wie die eigene for Schleife die alles mit 0en befüllt)