14

What is the point of static char THIS_FILE[] = __FILE__;?

Intro: What does it do? Where does it come from?

MFC, Microsofts native class library for Windows, has a DEBUG_NEW macro that tracks memory allocations and the place they happened (in the user code).

For this to work, the VS wizard puts the following code block into every cpp file: (not in header files)

#ifdef _DEBUG
    #define new DEBUG_NEW
    #undef THIS_FILE
    static char THIS_FILE[] = __FILE__;
#endif

and the debug new macro is defined as (in afx.h):

#define DEBUG_NEW new(THIS_FILE, __LINE__)

The whole machinery will result in meaningful leak detection output like:

Detected memory leaks!
Dumping objects ->
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {615} normal block at 0x04081CE0, 56 bytes long.
 Data: <¬9Í]            > AC 39 CD 5D 13 00 00 00 13 00 00 00 01 00 00 00 
c:\my\dev\path\myfile.cpp(237) : {614} normal block at 0x04087FC0, 4 bytes long.
 Data: <ð   > F0 1C 08 04 
Object dump complete.

So, what's the question again?

What leaves me puzzled is what the THIS_FILE char array is for. The machinery doesn't make sense. If they'd defined DEBUG_NEWjust as:

#define DEBUG_NEW new(__FILE__, __LINE__)

They could just place it in a header and be done with it instead of having that ifdef block in every file.

So, what's the point of THIS_FILE?

(Incidentally, this is exactly what MS' CRT does with malloc and _malloc_dbg where the debug macro is defined in the header crtdbg.h as: 

#define   malloc(s)             _malloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)

)

So again, why is it done the complicated way in the MFC DEBUG_NEWmacro when the simple way would work (better)???

Update: Ha! I recently noticed that the VS2005 wizard does not put the definition of THIS_FILE into a generated cpp file.

Investigating it, it seems that MS decided some time ago, that it is not neccessary anymore, as in afxtempl.h the following is defined:

#undef THIS_FILE
#define THIS_FILE __FILE__

Still, I guess the question keeps being the same, as to why it was ever neccessary. (And I guess the answer with the memory requirement way back then is pretty valid.)

Martin Ba
  • 37,187
  • 33
  • 183
  • 337

3 Answers3

9

The debug allocator stores a pointer to the file name in the heap block. Just 4 bytes instead of having every allocated block also having to allocate room for the file name.

Note that this can cause loss of debug info when the leaked block was allocated by a DLL and that DLL was unloaded by the time the leak report is generated.

Only the character array THIS_FILE is guaranteed to be always the same in the translaton unit. Not __FILE__, that's a literal. And two literals are not guaranteed to have the same address, even if they have the same value, meaning that a compiler could create a distinct literal -- and use up memory -- for each use of __FILE__.

Martin Ba
  • 37,187
  • 33
  • 183
  • 337
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Wouldn't the compiler already store the literal it used as the parameter to the `new` function call? Maybe it's to prevent multiple literals from taking too much space. – Mark Ransom Nov 07 '12 at 20:10
  • It is and that mattered in old versions of VS. MFC is *ancient*. – Hans Passant Nov 07 '12 at 20:14
  • I don't get it. The signature for the debug new operator (`void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine); `) would always be the same, regardless whether I pass it `__FILE__` or `THIS_FILE`. So where is any memory saved? – Martin Ba Nov 07 '12 at 20:20
  • 2
    Only THIS_FILE is guaranteed to be always the same. Not `__FILE__`, that's a literal. And two literals are not guaranteed to have the same address, even if they have the same value. – Hans Passant Nov 07 '12 at 20:27
0

I believe, and I could be wrong, that this is delineate the blocks of memory inside the compiled exe. This would help if you were to obtain an exception you could follow back the chain of memory addesses to find the offending code, given you knew what address the dll/exe was loaded at.

Joel Lucsy
  • 8,520
  • 1
  • 29
  • 35
0

__FILE__ is the same throughout the whole file while __LINE__ changes on every line. So if you have lots of debugging code in a file, older compilers that did not merge constants well, would have a lot of unnecessary copies of the string "filename.ext". You may be able to check the difference with something like -fno-merge-constants (sorry, thats the gcc CFLAG for it, not sure for VS). Most compilers now merge constants by default, making that definition unnecessary.

technosaurus
  • 7,676
  • 1
  • 30
  • 52