Re: macros question about new operator replacement
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.
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.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34