Prüfen ob Variable mit new Speicher zugewiesen wurde

estartu

CStoll schrieb:

(PS: Wie soll die Verarbeitung am Konstruktor vrobeikommen ;))

Indem ein anderer Konstruktor aufgerufen wird?

pale dog

CStoll schrieb:

Woher der Speicher stammt, auf den ein Zeiger verweist, kannst du nicht feststellen.

unter windoofs kannste damit feststellen, ob der pointer eine heap-adresse ist oder nicht: http://msdn2.microsoft.com/en-us/library/aa366708.aspx

Jochen Kalmbach

pale dog schrieb:

unter windoofs kannste damit feststellen, ob der pointer eine heap-adresse ist oder nicht: http://msdn2.microsoft.com/en-us/library/aa366708.aspx

Naja... das mag ja gehen wenn Du den Speicher mittel "HeapAlloc" allokiert hast, aber nicht mit der CRT (da zumindest im Debug-Build noch Fill-Bytes vorne und hinten angefügrt werden; auch wird eine eigene Link-Struktur vorangestellt; somit ist der Zeiger nie der, welcher vom *richtigen* Heap allokiert wurde)!

CStoll

pale dog schrieb:

CStoll schrieb:

Woher der Speicher stammt, auf den ein Zeiger verweist, kannst du nicht feststellen.

unter windoofs kannste damit feststellen, ob der pointer eine heap-adresse ist oder nicht: http://msdn2.microsoft.com/en-us/library/aa366708.aspx

Was hat denn bitteschön HeapValidate() mit new zu tun? Das kann nur den Speicher überwachen, den du von HeapAlloc() angefordert hast.

@estartu: OK, gutes Argument

Martin Richter

AndyDD schrieb:

Dann brauchst Du vor delete nur schauen, ob der Zeiger NULL ist oder nicht.

Das ist unnötige ein delete auf einen NULL zeiger ist immer sicher!
Das dämliche testen p!=0 kann man sich zu 100% sparen!

// Code der vüllig OK is:
char *p = NULL;
delete [] p;

pale dog

Jochen Kalmbach schrieb:

pale dog schrieb:

unter windoofs kannste damit feststellen, ob der pointer eine heap-adresse ist oder nicht: http://msdn2.microsoft.com/en-us/library/aa366708.aspx

Naja... das mag ja gehen wenn Du den Speicher mittel "HeapAlloc" allokiert hast, aber nicht mit der CRT (da zumindest im Debug-Build noch Fill-Bytes vorne und hinten angefügrt werden; auch wird eine eigene Link-Struktur vorangestellt; somit ist der Zeiger nie der, welcher vom *richtigen* Heap allokiert wurde)!

du hast recht, ich hab's ausprobiert.
die adressen, die ein 'new' liefert, sind andere, als die, die HeapWalk ausspuckt
sch... windows!

Martin Richter

Was hat das mit Windows zu tun?

Das hat etwas mit der Entwicklungsumgebung zu tun. Andere C++ Compiler machen es nicht anders und implementieren auch eigene Heaps...

pale dog

Martin Richter schrieb:

Andere C++ Compiler machen es nicht anders und implementieren auch eigene Heaps...

warum kann ein compiler, der sowieso code für windows erzeugt, nicht die system-heaps benutzen?
wär' doch viel cooler, es gäbe dann auch weniger probleme mit DLL's, die sonst immer ihre eigene CRT kopie einbinden...

hustbaer

VC8 zumindest kann den Process Heap verwenden.
Finde ich aber doof, da der dummerweise scheisse langsam ist

Davon abgesehen: wenn Speicher mal dynamisch angefordert wird und mal anders mah ihc immer 2 Zeiger. Den über den der Speicher angesprochen wird, und einen eigenen zum löschen. Wenn man new verwendet setzt man beide und sonst eben nur den ersten.

Martin Richter

pale dog schrieb:

warum kann ein compiler, der sowieso code für windows erzeugt, nicht die system-heaps benutzen?
wär' doch viel cooler, es gäbe dann auch weniger probleme mit DLL's, die sonst immer ihre eigene CRT kopie einbinden...

Performance ist ein guter Grund. Und der Systemheap ist einfach lahm bei großer Anzahl kleiner Elemente!
Aber selbst in dem Fall, dass der Systemheap verwendet wird, heißt dies nicht, das new nicht weitere Informationen in dem Speicherblock ablegt (z.B. die Größe des Arrays, der allokiert wurde) und der Zeiger der returniert wird definitv anders ist als die Adresse des HeapBlocks.

Einen Speichermanager verwenden nur die .NET Programme, und dasist auch nicht der System Heap