static char THIS_FILE[] = __FILE__; ? MFC, Microsofts native Klassenbibliothek für Windows, enthält ein Makro DEBUG_NEW , das Speicherzuordnungen und den Ort, an dem sie aufgetreten sind (im Benutzercode), verfolgt.
Damit dies funktioniert, fügt der VS-Assistent den folgenden Codeblock in jede cpp-Datei ein: ( nicht in Headerdateien)
%Vor% und das neue debug-Makro ist definiert als (in afx.h ):
Die gesamte Maschine wird zu einer aussagekräftigen Leckerkennungsausgabe wie:
führen %Vor% Was mich verwirrt, ist das Array THIS_FILE char. Die Maschinerie macht keinen Sinn. Wenn sie DEBUG_NEW genau wie folgt definiert hätten:
Sie könnten es einfach in eine Kopfzeile einfügen und damit fertig sein, anstatt den ifdef -Block in jeder Datei zu haben.
Also, was ist der Sinn von THIS_FILE ?
(Dies ist übrigens genau das, was MS CRT mit malloc und _malloc_dbg macht, wenn das Debug-Makro in der Kopfzeile crtdbg.h wie folgt definiert ist:
)
Also, warum ist es so kompliziert im MFC DEBUG_NEW Makro, wenn der einfache Weg (besser) funktioniert?
Aktualisierung: Ha! Ich habe kürzlich festgestellt, dass der VS2005-Assistent die Definition von THIS_FILE nicht in eine generierte cpp-Datei schreibt.
Nach der Untersuchung scheint MS vor einiger Zeit entschieden zu haben, dass dies nicht mehr notwendig ist, da in afxtempl.h Folgendes definiert ist:
Trotzdem denke ich, dass die Frage immer dieselbe ist, warum es überhaupt nötig war. (Und ich denke, die Antwort mit der Speicheranforderung ist damals ziemlich gültig.)
Der Debugzuordner speichert einen -Zeiger für den Dateinamen im Heap-Block. Nur 4 Bytes, anstatt dass jeder zugewiesene Block auch Platz für den Dateinamen reservieren muss.
Beachten Sie, dass dies zu einem Verlust von Debug-Informationen führen kann, wenn der ausgelaufene Block von einer DLL zugewiesen wurde und diese DLL zum Zeitpunkt der Erstellung des Leckberichts entladen wurde.
Nur das Zeichenarray THIS_FILE ist in der Translationseinheit garantiert immer gleich. Nicht __FILE__ , das ist ein Literal. Und zwei Literale haben nicht garantiert dieselbe Adresse, auch wenn sie denselben Wert haben, was bedeutet, dass ein Compiler für jede Verwendung von __FILE__ ein eindeutiges Literal erstellen und Speicher verbrauchen kann.
Ich glaube, und ich könnte falsch liegen, dass dies die Speicherblöcke in der kompilierten exe beschreibt. Dies würde helfen, wenn Sie eine Ausnahme erhalten würden, könnten Sie der Kette von Speicheradressen folgen, um den fehlerhaften Code zu finden, vorausgesetzt, Sie wüssten, an welche Adresse die dll / exe geladen wurde.
__FILE__ ist in der gesamten Datei gleich, während __LINE__ sich in jeder Zeile ändert. Wenn Sie also viel Debugging-Code in einer Datei haben, würden ältere Compiler, die Konstanten nicht gut zusammengeführt haben, viele unnötige Kopien der Zeichenkette "filename.ext" haben. Sie können vielleicht den Unterschied mit etwas wie -fno-merge-constants überprüfen (sorry, das ist der gcc CFLAG dafür, nicht sicher für VS). Die meisten Compiler führen jetzt standardmäßig Konstanten zusammen, was diese Definition unnötig macht.
Tags und Links memory-leaks visual-c++ mfc visual-studio-debugging memory-leak-detector