“Exercise good memory-related coding practices by creating a comprehensive program to keep memory errors under control. Memory errors are the bane of C and C++ programming: they’re common, awareness of their importance for over two decades hasn’t eradicated them, they can impact applications severely, and few development teams have a definite plan for their management. The good news, though, is that they needn’t be so mysterious.”
Techniques for Memory Debugging
Submitted by BlueVoodoo 2007-02-19 General Development 4 Comments
Whilst good programming practices are always better than debugging I’m surprised that the author didn’t mention valgrind:
It makes very hard to track errors (use of uninitialized values, leaks, double frees, buffer overflows, etc…) extremely easy to spot and fix, it’s really a boon.
I really think the solution is to not use a framework where memory leaks are allowed. Thus, garbage collection has become the norm. Even in the C++ world, I would use “safe” pointers, and there are frameworks that greatly assist in memory allocation/deallocation. Myself, I don’t want to ever go back to manually ensuring errors like memory leaks, null pointers, array boundaries, etc, do not occur. These things should be dealt with at the framework level, or even at the language level. The only exception to this for now is at the OS level (such as drivers, kernels), where the overhead is too much. However, even that will probably change some day.
I’m a programmer, and my philosophy is never trust the programmer. The same goes with the Database. Enforce your business rules at the database level. There is more overhead to database constraints, etc., but I believe the price is worth it.