Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
It's so important to understand this clearly that I'll repeat it now in slightly different words. Many development tools require long training and adoption of a narrow methodology; they don't "play well" with many of the practices already in place. Memory-testing tools aren't like that. Instead, they're all easy to install, easy to begin using, and feasible to integrate with the way you already work. They work inside Makefiles, and plug into popular integrated development environments (IDEs).
The consequence is that I've had the same experience over and over since the first time I used a commercial memory-testing tool in the early 1990s: Once I have it properly licensed, I'm able to apply the tool to a very large existing application in a short time. When I do so, the tool invariably finds errors in production code—often important errors that would have been damaging and expensive if left in place to turn up in customers' operations.
All the C and C++ programming teams I've observed make memory errors. Memory-testing products are successful: They find a large percentage of all errors in memory use. For me, the memory-tool products are great investments. Payment of a manageable licensing fee multiplies the reliability and maintainability of all the C-coded applications within an organization.
Of course, these memory-testing products have a few liabilities. I've known a few good C or C++ programmers who never learn to read the reports. While I'm still not sure how or why this happens, you should at least make a point of trying the memory tools before you buy one. Make sure the diagnostics of an evaluation version make sense to you before you commit to a license.
Mechanical diagnostic tools like memory debuggers also tend to be "noisy:" they can report "false positives," that is, apparent memory faults where there are none. C++ runtimes which implement cin and cout as static objects which allocate heap memory, for example, masquerade as memory leakers. This illustrates that one of the key differentiators of the commercial memory tools is the convenience with which they permit customization. A good tool makes it easy to specify instances or even classes of usages which the developer declares "legal." When I perform diagnostic scans, I expect to end up with source code which is completely clean—I've either corrected or explicitly analyzed every identified memory problem.
Finally, memory tools degrade performance. They slow the runtime speed of a C-coded application, sometimes drastically. While I like to run with memory testing turned on all the time, applications that require a lot of memory and CPU cycles bog down too much to allow this technique.
Overall, though, memory-testing tools are among the best investments that a development team can make. (Write me at claird@phaseit.net and tell me about your experience.)
And if license restrictions, including the fee, are an issue for you, you'll look forward to the next installment of this series on memory hygiene, where I explain the fee-free memory-testing tools available. Until then, good luck with your leaks and overwrites.