gcc support for memory debuggers (operator delete) ?

[Felvegi Peter Andras]

hello,

> This would be a deviation from the C++ Standard.  As much as the
> asymmetry between new and delete sucks, it's part of the language, and
> any extension we introduce to this effect will still require changes
> in programs that don't use this extension, so it won't solve the
> problem.  In C++, operator delete (void *, other args) is called
> *only* when the constructor implicitly called by a new (other args)
> expression throws, to delete the incompletely-constructed object.

this would be a feature that is _off_ by default, and everyone who turns
it on should face the consequences. it should be used only for
debugging: one shouldn't use it to pass info to delete other than
file/function/line, like info about program state, etc.

 >
> >   * force the call of operator delete even if the pointer is NULL
>
> Doesn't sound like something you would want to enable by default.

the same goes here, too : this feature should be off by default.

> except, maybe, for operator precedence issues.  Remember that delete
> may be part of a more complex expression, and then using the comma
> operator may get things wrong.

then a conditional expression might be a better approach.

 considering that only file/function/line info is needed to be passed, a
slightly different approach might work aswell, w/o violating the C++
standard: through a few builtin variables. like
__builtin_delete_call_site_line/func/file or something like that.  the
overloaded delete operator could use this info then. and, for the sake
of simmetry and efficiency, similar builtins should go with new.  this
has the additional benefit that it will work even with classes that have
their own op new/del. with the original '#define new new(..)' this is
not possible.
 this feature should be also off by default, since the variables have to
be updated in a stack-like manner, and this overhead is not needed
normally.

 any ideas, opinions ?

						cheers, p