Quote Originally Posted by Speedo View Post
In reality, however, it is often not so trivial to implement that simple phrase.
That's why programs such as Purify, BoundsChecker, Insure++, and others exist, and in some cases, sell for very hefty prices. These companies know that solving memory allocation and leak issues is not trivial for most non-trivial applications.

The underlying fact is that professional programmers make mistakes, mistakes that cannot be easily solved by looking at code, or even running in a debugger. When a codebase takes thousands, if not millions of different execution paths depending on data, input, etc. a human being, regardless of their knowledge of C++ and memory handling, may not be able to solve complex memory allocation problems in any reasonable time.

If you're coding your own app that's used in-house, that's one thing. When you're coding an app used by the consumer market or for clients, and you have competition from other vendors, any time wasted debugging could mean money. To avoid, or at the very least, lessen the chances that errors occur, you use the safest techniques that are at your disposal.

When code reviews were given at a company I worked for, whenever the reviewer saw "new/delete", and the reason was not obvious (polymorphism, for example) the reviewer would ask "why are you doing this?". If the question cannot be answered reasonably, or if alternatives existed, the code was given back to you to correct or change. Even if it's so safe to use "new/delete", the code was to be corrected. Things like this:
Code:
void foo()
{
    char *p = new char [100];
    //....
    delete [] p;
}
Code like this, even if it's safe, was thrown back at you to fix, and IMO, for good reason.

Regards,

Paul McKenzie