This C++ class ensures that memory is allocated and freed correctly and eases the normally tedious task of tracing memory leaks. Full working example included.

I've written applications that were bad and I've written some that were perfect, though it took me years to figure out why a few of the perfect applications were chewing 75% of my RAM. No matter, their still perfect to me... but on a serious note, have you ever written any C or C++ code? Yes? Good - Then you are already familiar with memory leaks!

Memory leaks occur when you allocate RAM and do not free it. On modern OS's these memory leaks are only potentially detrimental for the lifetime of the running application, that is, the badly managed resources are cleaned up after the leaky application is closed (or unexpectedly terminated). That said, memory leaks really begin to haunt you when writing long running applications or more specifically: services.

These leaks can be more than frustrating, I've turned my back on applications that I've dedicated years to because the manner of my memory's escape was just too elusive (e.g. I've written bad applications).

How can we solve such a problem? Well, you can either attempt to be perfect and (on near certain failure) dump five times the development time into debugging... or use some manner of memory tracking.

I developed one of these "memory trackers" that I now include in all of my C++ projects – yes, even the small ones – you never know what they'll grow into.

I call this magic tool: CMemoryPool (though, it's not really a memory pool).

How's it work? Well it's simple really - it has 4 modes which are set by defining pre-processors.

Modes of Operation:

• Disabled
• In disabled mode, the memory tracker code is collapsed down to calls to your native malloc(), calloc(), and realloc(). Fully optimized - this mode is for the final release of your product.
• General
• In general mode, the memory tracker will keep track of the allocations that your program makes and raise a debug break when the class is deconstructed if all of the allocations that it witnessed were not cleaned up properly. This mode is faster than the following modes and that's pretty much the end of its advantages.
• Advanced
• In advanced mode (which should have been called "default mode"), the memory tracker will keep track of each allocation that your application makes as well as the number of bytes per allocation and the source code file name and the line number in the source file that the allocation originated from. Much like the previous mode, the class will trigger a debug break when the class is deconstructed if your application has not been well behaved.
• Verbose
• Verbose mode is slow. It's actually more than slow but I don't want to appear dramatic by telling you that it's "insanely slow" or "near unusable" - despite the fact that these statements would be true. This mode functions exactly like the previous mode (Advanced) but additionally it opens a console (if you didn't already open one) and prints verbose information about every memory allocation, reallocation and free to the console. Yea, you think memory allocation is slow now – try Verbose mode!

One last thing that should be noted about the memory tracker is that it is multi-thread safe – very multi-tread safe. It's even safe to use with non-multi-thread safe standard libraries. This functionality can be disabled when running in the final "disabled" mode for your final release by ensuring that the "Sequential When Optimized" pre-processor is not defined in the class header.

You're not still reading are you? ....I call B.S.

Well, if your that interested, grab a copy of the CMemPool and start saving time!!