 |
|
|
 |
|
|
|
| CMemPool |
|
| Downloads |
|
12,060 |
| User Rating |
|
(Rate) |
| Last Updated |
|
8/14/2009 |
| License |
|
MIT License |
|
|
|
| Recommended Release |
|
| Version |
|
1.0.0.5 |
| Date |
|
8/14/2009 |
| Status |
|
Stable
|
|
|
|
|
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!!
|
|
|
|
|
|
| |
Copyright © 2024 NetworkDLS.
All rights reserved.
|
|
|
|
|
|
|
|
|