macros question about new operator replacement

[asm23]

Hi, all.

I have a simple code, it is used in a replacement of the new operator to
support a debug version of new.

#define NEW new (dmalloc, __FILE__, __LINE__)
#define new NEW

void f ()
{
int *intp = new int;
}

Using gcc -E command will give the code below:

void f ()
{
int *intp = new (dmalloc, "a.c", 8) int;
}

My question is:

Why we need *two* macros.
Should one macro be enough:
#define new new (dmalloc, __FILE__, __LINE__)

And what's the replace sequence of these two macros?(How the C
preprocessor do the replacement?)

Thanks in advance.

 

[James Kanze]

I have a simple code, it is used in a replacement of the
new operator to support a debug version of new.

#define NEW new (dmalloc, __FILE__, __LINE__)
#define new NEW

void f ()
{
int *intp = new int;
}

Using gcc -E command will give the code below:

void f ()
{
int *intp = new (dmalloc, "a.c", 8) int;
}

My question is:

Why we need *two* macros.

You don't.

But the code in question will result in undefined behavior
if you include any standard header, and probably fail to
compile if you define the macro before the include.

Should one macro be enough:
#define new new (dmalloc, __FILE__, __LINE__)

And what's the replace sequence of these two macros?(How
the C preprocessor do the replacement?)

"new" is replaced by "NEW", then "NEW" is replaced by "new
(dmalloc, __FILE__, __LINE__)".

 

[asm23]

Thanks James for your help. Actually, I'm reading these links, I'm
trying to detect memory leak by using ."A Cross-Platform Memory Leak
Detector".

http://wyw.dcweb.cn/leakage.htm

The author try to define his own debug_new routing, in which any memory
allocation and deleting can be recorded.

He just use these mechanism. It seems he just override of the *operator
new*.

For the replacement issue, it seem there are two steps, and macros can
be called recursively.

Say, "new" is replaced by "NEW", then "NEW" is replaced by "new
(dmalloc, __FILE__, __LINE__)".

then, whey the "new" in "new(dmalloc, __FILE__, __LINE__)" can't be
replaced?


Thanks!

 

[James Kanze]

Thanks James for your help. Actually, I'm reading these links,
I'm trying to detect memory leak by using ."A Cross-Platform
Memory Leak Detector".

The author try to define his own debug_new routing, in which
any memory allocation and deleting can be recorded.

The author also explains the restrictions, sort of: what he
doesn't mention is that they mean that it will not work if any
standard headers are included after the new new is defined.

He just use these mechanism. It seems he just override of the
*operator new*.

Actually, he posts an update (credited to an idea from Greg
Herlihy) in which he doesn't override operator new, and which
works for placement new. It's still formally undefined behavior
if you include a standard header, but done correctly, it's verly
likely to work in practice.

For the replacement issue, it seem there are two steps, and
macros can be called recursively.

I don't know why there are two steps, it's not necessary. But
macros can't be called recursively. During expansion of a
macro, it's name is "hidden", so that it won't recurse.

Say, "new" is replaced by "NEW", then "NEW" is replaced by "new
(dmalloc, __FILE__, __LINE__)".

then, whey the "new" in "new(dmalloc, __FILE__, __LINE__)" can't be
replaced?

Because the standard says so.

 

[asm23]

The author also explains the restrictions, sort of: what he
doesn't mention is that they mean that it will not work if any
standard headers are included after the new new is defined.


Actually, he posts an update (credited to an idea from Greg
Herlihy) in which he doesn't override operator new, and which
works for placement new. It's still formally undefined behavior
if you include a standard header, but done correctly, it's verly
likely to work in practice.


I don't know why there are two steps, it's not necessary. But
macros can't be called recursively. During expansion of a
macro, it's name is "hidden", so that it won't recurse.

Thanks James. I see.