ZFX + Developia

Ich habe mich gestern mit memory leak tracking auseinander gesetzt. Das Ziel war es, den Allokationsort des memory leaks auszugeben.

Laut MSDN folgendes schreiben:
anschließend ruft man am Ende des Programms
auf und man bekommt angeblich den Dateinamen mit Zeilennummer ausgegeben, wenn ein Pointer nicht gelöscht wird.
Das Makro _CRTDBG_MAP_ALLOC sorgt angeblich dafür, dass Dateiname und Zeilennummer mit ausgegeben werden. Das hat bei mir nicht geklappt, weil... ja.. warum eigentlich.. keine Ahnung. Laut Kommentaren im MSDN liegt es daran, dass der Precompiled header die Datei afx.h einbindet und die wiederum die crtdebug.h.
Das Makro _CRTDBG_MAP_ALLOC muss allerdings definiert sein, bevor crtdebug.h eingebunden wird, damit die Ausgabe funktioniert. Durch die Einbindung von afx.h in stdafx.h (dem precompiled Header) kann man sich das _CRTDBG_MAP_ALLOC auch fast sparen..

Zusätzlich zu dem bisher genannten Problem ergibt sich die Tatsache, dass man eigentlich nach der Main Methode und nach Deallokierung sämtlicher Speichereinheiten aufrufen muss. Das bekommt man hin, indem man in der Main.cpp als erstes eine Struktur definiert:
Anschließend erstellt man als erstes Objekt in der main.cpp eine Instanz dieser Struktur. Diese landet dann ganz unten auf dem Stack und wird dementsprechend als letztes gelöscht. Also wird erst nach Deallokierung aller mit "new" erstellten Sachen aufgeräumt, was ja das Ziel war.

Man kann auch einfach folgenden Code aufrufen, anstatt dier Struktur zu nutzen: Muss dann auch so früh wie möglich gemacht werden.

Es bleibt das Problem, dass ich keine Zeilennummern habe, vom Dateinamen mal ganz zu schweigen. Dann bin ich über folgenden Codeausschnitt gestolpert:
Es funktioniert perfekt und man kann Memoryleaks ziemilch schnell finden und beheben.
Daran sind in meinen Augen aber zwei Sachen komisch:

1. Ist folgendes nicht effizienter? 2. Ich verstehe nicht genau, was hier passiert. man tauscht also durch .
Wird also immer, wenn ich new eintippe ein anderer new-Operator aufgerufen, der Speicherblock, Dateinamen und Zeilennummer speichert?

Hier nochmal der ganze Code an einem Stück:
Der Anfang von stdafx.h:
Hier noch eine weitere Quellenangabe mit Pro und Contras zum Thema.

Brainsmith hat geschrieben:2. Ich verstehe nicht genau, was hier passiert. man tauscht also

Code: Alles auswählen

new

durch

Code: Alles auswählen

new(_NORMAL_BLOCK, __FILE__, __LINE__)

.
Wird also immer, wenn ich new eintippe ein anderer new-Operator aufgerufen, der Speicherblock, Dateinamen und Zeilennummer speichert?

Japp. Zusätzliche Parameter werden bei überladenem new in der Mitte übergeben, hast du also deklariert:
void * operator new (size_t size, foo theFooParameter);
dann rufst du den per
Type * newInstance = new (myFoo) Type;
auf. Ergo hat die CRT einen operator new überladen, der als zweiten bis vierten Parameter int (dazu sind _NORMAL_BLOCK und _CLIENT_BLOCK #definet), char const * und int erwartet. Und der wird dann jedes Mal aufgerufen, wenn du new schreibst.

Danke für die Antwort. Verwirrt mich aber doch schon irgendwie. Schließlich steht dann nach dem Makro hinterher:
Aber eine Funktion ruft doch immer nur den nächsten Klammerblock auf, oder?


Ich habe den memory leak detector letztens mal bei einem Kollegen implementiert und allein die Memoryleak-Ausgabe in eine Textdatei hat 3,5 MB verbraucht. Das hat man davon, wenn man ein Projekt von VB.NET nach VC++ konvertiert.. =D

Brainsmith hat geschrieben:Danke für die Antwort. Verwirrt mich aber doch schon irgendwie. Schließlich steht dann nach dem Makro hinterher:

Code: Alles auswählen

new [Typ] ([Usereingaben]) ([Speicherblock], [Dateiname],[Zeilennummer])

Nö.
new int(1);
wird zu
new (_NORMAL_BLOCK, "foo.cpp", 42) int(1);
und ruft erst den Operator
void * new(size_t size, int blockType, char const * file, int line);
und dann den Kopierkonstruktor von int auf.

Brainsmith hat geschrieben:Aber eine Funktion ruft doch immer nur den nächsten Klammerblock auf, oder?

new ist ja auch keine Funktion, sondern ein Operator. Wenn du x << y; schreibst, sind da überhaupt keine Klammern und es wird trotzdem was mit Parametern aufgerufen. Noch dazu: Da werden nicht die endgültigen Parameter übergeben; z.B. erwartet der Operator ja noch die Größe des zu allokierenden Datenbereichs in Bytes, die erst noch durch Compiler-generierten Text berechnet wird.

Ok, ich glaub, so langsam wirds klarer..
Danke nochmals.