macros question about new operator replacement
asm23
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__)".
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
asm23
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!
Pete Becker
Because that's how macros are defined. During the expansion of a macro,
text with the same name as the macro is not replaced.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
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".
> 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.
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
> On May 24, 2:18 pm, asm23 <asmwarr...@gmail.com> wrote:
>> 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.
>
> 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.
Thanks James. I see.