2009-02-06 6 views
10

Wenn Sie eine neue MFC-Anwendung erstellen, erstellt der Assistent den folgenden Code-Block in fast jeder CPP-Datei:Sind "#define new DEBUG_NEW" und "#undef THIS_FILE" etc. eigentlich notwendig?

#ifdef _DEBUG 
#define new DEBUG_NEW 
#endif 

und manchmal fügt es auch dies:

#undef THIS_FILE 
static char THIS_FILE[] = __FILE__; 

Ich würde entfernen möchte Dieser Code aus meinen CPP-Dateien, wenn es redundant ist. Ich verwende eine MFC-App mit C++/CLI auf VS2008.

Ich habe versucht, in Debug ausgeführt nach dem Löschen dieses Codes von einem CPP, und es scheint zu funktionieren. "neue" Variablen funktionieren gut, es gibt keine Lecks und ASSERT-Dialoge zeigen den korrekten Dateinamen an und springen zur fehlerhaften Zeile.

Kann mir jemand sagen, was es tut und ob es sicher ist, es zu löschen?

Antwort

10

Es ist vollkommen sicher, dies zu löschen. Es ist eine Debugging-Hilfe; Wenn Sie es zurücklassen, werden Warnungen im Ausgabefenster von Speicherlecks erzeugt, die Sie beim Beenden des Programms haben.

+0

Sind Sie sicher? VS2008 zeigt weiterhin einen Speicherleckobjektspeicher an, nachdem ich den Codeblock gelöscht habe. Vielleicht war das bei VC6 so oder so ...? – demoncodemonkey

+1

Entschuldigung, ich habe gerade bemerkt, dass es eine Feinsinnigkeit zu dem gibt, was Sie gesagt haben - wenn der Code da ist, zeigt das Ausgabefenster den Dateinamen und die Zeile mit dem Speicherleck, anstatt nur zu zeigen, dass ein Speicherleck vorliegt. – demoncodemonkey

+0

Das erklärt also den ersten Teil des generierten Codes. Was ist mit dem 2. Teil? #undef THIS_FILE static char DIES_FILE [] = __FILE__; – demoncodemonkey

1

Auf Microsoft Visual C++ 2010 kann ich den gesamten Code entfernen und nur eine # define NEW DEBUG_NEW in eine Kopfzeile einfügen, und ich habe immer noch die richtigen Speicher Leckberichte, z.

Detected memory leaks! 
Dumping objects -> 
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {7508} normal block at 0x029B9598, 54 bytes long. 
Data: <    > E4 B8 C9 00 12 00 00 00 12 00 00 00 01 00 00 00 
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {7501} normal block at 0x029B94A8, 28 bytes long. 
Data: <    > E4 B8 C9 00 05 00 00 00 05 00 00 00 01 00 00 00 
f:\source\agent\agent\deviceid.cpp(21) : {7500} normal block at 0x029CDFC0, 8 bytes long. 
Data: <  > A8 95 9B 02 B8 94 9B 02 
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {6786} normal block at 0x029C0D88, 160 bytes long. 
Data: <  G  > E4 B8 C9 00 19 00 00 00 47 00 00 00 01 00 00 00 
f:\source\agent\sysinfo\sysinfo.cpp(27) : {6733} normal block at 0x029B84D8, 92 bytes long. 
Data: <    > 00 00 00 00 00 10 00 00 00 00 01 00 FF FF FE 7F 
Object dump complete. 
+3

Nein, du bekommst nicht die ganze Information. Beachten Sie, dass der Code, den Sie anzeigen, nur das Leck in 'strcore.cpp' zeigt, das anzeigt, dass Sie ein CString-Objekt (oder ähnliches) verloren haben. Mit dem korrekten Offset DEBUG_NEW/THIS_FILE würde es auch den Ort in * Ihrem * Code melden, wo Sie das 'neue' gemacht haben –