DatensatzAuslesen::DatensatzAuslesen(CString Filename)
{
	Sheet = new CSpreadSheet(Filename,";",FALSE);
	CString Error = Sheet->GetLastError();
	//MessageBox(0,Error,0,MB_OK);
}

Wenn dies aufgerufen wird, wird Sheet 'erstellt'
Im Header steht

CSpreadSheet* Sheet;

Es muss nicht sein, dass DatensatzAuslesen aufgerufen wird. Ohne delete bekomme aber ein Speicherleck.

Sheet = NULL;

Das ist eh ne Pflicht, wenn du mit Zeigern arbeitest!

So kannst du vor delete auf NULL prüfen.
Und nach dem delete setzt du ihn auch wieder NULL.

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

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

Indem ein anderer Konstruktor aufgerufen wird?

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

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 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

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 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!

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

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...

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.

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