"Alf P. Steinbach" <al***@start.nowrote:
My code looks something like this:
void* operator new( std::size_t size, const char* fileName, int line );
void* operator new[]( std::size_t size, const char* fileName, int line );
#define DEBUG_NEW new(__FILE__, __LINE__)
#define new DEBUG_NEW
void operator delete( void* address ) throw();
void operator delete[]( void* address ) throw();
With a standard-conforming compiler this will reproduce Microsoft's
problem with MFC, that is, leaks when constructors throw.
The system I use the above in, doesn't have exceptions (constructors
can't throw) so I haven't had the problem.
As I understand it, I should provide matching delete functions to avoid
the problem you are talking about
:
void operator delete( void* address, const char*, int ) throw();
void operator delete[]( void* address, const char*, int ) throw();
Correct?
Bug general advice: don't do use things you don't understand, at the
architecture level where it affects all code.
Instead, use proven techniques, such as smart pointers, and tools, such
as e.g. ValGrind. I've never needed to use it myself, so I don't know
from first-hand experience how effective it is at detecting a sloppy
programmer's mess. But as I understand it, for those who prefer to use
days and weeks to fix up their mess afterwards, plus ditto extra time
for any maintainance, instead of minutes or hours Doing It Right in the
first place, ValGrind & friends are indispensable tools and work OK.
Well, in my case, it's me fixing other peoples messes, but I understand
your point.
