Question:
C++/MFC - Why do I need this ugly repititive code in all MFC source files?
anonymous
2011-04-24 01:00:45 UTC
ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

I know it is used for automatic memory leak detection! But why do I need to put it in every source file. Why can't I put it in a header file like StdAfx.h, which is included in every source file.
Four answers:
?
2011-04-24 21:44:51 UTC
You can (and should) remove such code from all your source files! It's MS crap!

Here is how to do it, without losing any functionality:



1) Remove those ugly fat 5 or 3 lines of code from all your source files.



2) Just put the following 3 lines of code I mentioned below, at the bottom (after all headers) in the common header StdAfx.h or any other which you include in all source files.



#ifdef _DEBUG

#define new DEBUG_NEW

#endif



CAUTION – Only those 3 lines above and not all the 5-lines you have mentioned otherwise all detected memory leaks will take you to StdAfx.h and not the actual source file.



3) To verify if it continues to work, just leak some memory deliberately by allocating it with new and forgetting to delete it, (Make sure it is in that part of code which executes when you run your application). In a Doc/View project I would put it in InitInstance().



4) Rebuild and then Run by pressing F5 and then exit. See in the output window if the leaks have been detected and you are able to locate the code by double clicking on the line.



That should work. If it doesn’t, do let me know at:

neerajk143@yahoo.com



…………..



PROOF: Fortunately finally Microsoft realized this mistake and the two lines - #undef .... and static char THIS_FILE...., are no longer used in Visual Studio 2008 onwards. You can look at the wizard generated code and it is this:



#ifdef _DEBUG

#define new DEBUG_NEW

#endif



WHICH AGAIN I FIND IDIOTIC TO SAY THE LEAST! Indeed I agree these are required to be able to click on the leak warnings to locate the source. But why put it in every source file? The only sane reason to not put this code in a common header like StdAfx.h could be to use the leak detection in selective source files and not all. Which is insane! Why would I want to do that, when I can always build in Release mode to disable all memory leak detection? And what if I forget to put hem in a source file I didn't create using the wizard? IMHO, I think the only safe place to put them is StdAfx.h. But I am not sure when Microsoft is going to realize this.



EXPLAINATION for THIS_FILE:

In VC6 and newer versions of VC++ the macro THIS_FILE is defined in Afx.h as follows:



#define THIS_FILE __FILE__



This means wherever the expression THIS_FILE occurs in your source files, it is replaced by the __FILE__ macro. Given this, there seems to be no reason whatsover to undefine it with #undef THIS_FILE and then re-declare it as a static global variable. My best guess is that the line #undef THIS_FILE is a leftover from earlier versions of VC. And it seems they forgot to update the mfc class wizards! And my assumption is vindicated by VS2008 code. Also use of "static" keyword in global scope (using static keyword hides a global variable from other translation units) has been deprecated long back. It is considered a bad programming practice and a leftover from C. Why MS took it so long to realize it, only God knows.



I have seen lots of debates on the internet, regarding this and lots of justifications also. Like one or two here. Believe only what works. Do let us know if my solution works.
Cubbi
2011-04-24 17:09:59 UTC
__FILE__ is the standard C++ predefined preprocessor macro that is replaced by the name of the file that is currently being processed.



If you put this code in a header file, the value of __FILE__ and therefore the contents of the char array THIS_FILE will be the name of the header file (StdAfx.h in your example), defeating the purpose.
Vaibhav
2011-04-24 09:07:33 UTC
well maybe because it is a feature of preprocessor which works for each program separately

it is not like a function

it will work for the source of file in which it is written
?
2011-04-24 08:17:08 UTC
LOL. I have wondered about it for a long time now. Never got the answer.


This content was originally posted on Y! Answers, a Q&A website that shut down in 2021.
Loading...