Macro for debugging new through operator new syntax

[Carlos Martinez]

Hi all:

It's common to see the following macros:

#define DEBUG_NEW new(__FILE__, __LINE__)
#define new DEBUG_NEW

and overloading operator new for debugging purposes.
It usually works but there is a problem when use operator new syntax in code instead of directly use new. I can change my code but i can't change third party's code. Something like this:

int* j = static_cast<int*>(::operator new(sizeof(int)));

It's not common, but it appears occassionally.
With that syntax, new macro generates compilation errors.
Is there any way to fix this problem?

Thanks in advance

[Paul McKenzie]

Hi all:

It's common to see the following macros:

#define DEBUG_NEW new(__FILE__, __LINE__)
#define new DEBUG_NEW

and overloading operator new for debugging purposes.
It usually works but there is a problem when use operator new syntax in code instead of directly use new. I can change my code but i can't change third party's code. Something like this:

int* j = static_cast<int*>(::operator new(sizeof(int)));

It's not common, but it appears occassionally.
With that syntax, new macro generates compilation errors.
Is there any way to fix this problem?

Thanks in advance

If your goal is to overload new for debugging purposes (to find memory leaks), may I suggest you not do it at all.

Instead use constructs such as smart pointers (shared_ptr, etc.) instead of using new in a "naked" fashion. Then you have no worries concerning memory leaks. In this day and age of C++, unless you're creating your own allocator or data structure (at a low-level), using naked calls to new basically need not be done.

In addition, you need to also overload new[], not just new. Again, if your goal is purely for debugging purposes, then the solution is to not get yourself into a situation where you're using new in an unsafe way (use smart pointers). I maintain a large amount of source code myself, and there are few, if any calls to "new", unless the newed pointer immediately gets assigned to a smart pointer. Once I do that, memory leaks vanish.

Regards,

Paul McKenzie

[Carlos Martinez]

I am agree with you and next time i probably design the program in a different way using shared_ptr, but in the current code, I use smart pointers (shared_ptr), just for memory leaks for common data between different requests, but not all code has smart pointers. I have some containers and classes with naked pointers without ownership of the memory pointed to (That memory is owned by other containers with smart_pointers).
My problem are dangling pointers, not memory leaks, but i use operator new overloading for registering addresses. Using shared_ptr could prevent dangling pointers, but there are too many lines of code to change.
For detecting Dangling pointers I have a class registering references to the same addresses. This has a big overhead, but is disabled using macros with no overhead in production release.
That works well if i have my serialization code disabled (using macros too), but fails to compile with serialization enabled due to operator new syntax. That's why I post this question.

For future code, i must rethink my desing. Thanks for your response.