FXMemDbg.h File Reference

---

Detailed Description

Redefines the memory allocation routines on MSVC.

GNU/Linux has the extremely useful valgrind so if you're on that platform I suggest you go use that. If you're on MacOS X or FreeBSD, you're probably the least supported by me (but only because I don't have access to such a system).

MSVC, to Microsoft's credit, actually comes with plenty of memory leak and corruption detection code in its debug heap - it's just not fully enabled by default. This of course comes with the price of the debug heap not behaving like the release one (which famously in MSVC5 (or was it v4?) realloc() just plain didn't work) but nevertheless, with a small amount of extra work from you you can get most of the functionality of valgrind with less than a 5% loss in performance.

Usage:

If you wish to trap memory leaks, include this code after all other include's in your C++ file but before the main body:

#include <FXMemDbg.h>
#if defined(DEBUG) && !defined(FXMEMDBG_DISABLE)
static const char *_fxmemdbg_current_file_ = __FILE__;
#endif

In debug mode only, before your program quits, you'll get a list of all unfreed memory blocks and where they were allocated. The ones with source file names are your ones or ones within TnFOX itself. All extension code by me uses FXMemDbg and it's easy to modify fxdefs.h to have FXMALLOC() use it too.

Lastly, MSVC's debug heap runs a heap validation check every 1024 allocations and frees and this will usually catch memory corruption, though somewhat belatedly. You can force a check while trying to localise the cause during debugging using FXMEMDBG_TESTHEAP. I'd also look into _CrtSetDbgFlag() if you want more enhanced control (FXProcess sets it for the application).

Note:

If you wish to disable this facility, define FXMEMDBG_DISABLE. Note that it is disabled when compiled as release anyway.