Hi,

This is a spin-off question from a question I posted earlier in
comp.lang.c++.moderated (Why doesn't delete() set pointer to 0?).

Why was delete() defined as delete(void*) instead of delete(void*&)? The
latter definition would allow delete() to null the pointer.

Bjarne Stroustrup's has an item about this in his C++ Style and Technique
FAQ (http://www.research.att.com/~bs/bs_faq2.html#delete-zero) -- Why
doesn't delete zero out its operand? -- but the following in that FAQ
puzzles me.

[...]
C++ explicitly allows an implementation of delete to zero out an lvalue
operand, and I had hoped that implementations would do that, but that idea
doesn't seem to have become popular with implementers.
[...]

How can an implementation zero out the pointer when the pointer is passed by
value to delete??

Regards,

Marcel Loose.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marcel Loose wrote:

> Why was delete() defined as delete(void*) instead of delete(void*&)?
> The latter definition would allow delete() to null the pointer.
> [...]
> C++ explicitly allows an implementation of delete to zero out an
> lvalue operand, and I had hoped that implementations would do that,
> but that idea doesn't seem to have become popular with implementers.
> [...]
> How can an implementation zero out the pointer when the pointer is
> passed by value to delete??

It's not the implementation of "operator delete(void*)" that would
perform the zeroing, but the vendor specific implementation of the
delete statement -- remember that "delete p;" usually means something
like "p->~typeof(*p); operator delete(p);". This could instead be
"p->~typeof(*p); operator delete(p); p=0;" if p is an lvalue.


Marco

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Marcel Loose" wrote:
> Hi,
>
> This is a spin-off question from a question I posted earlier in
> comp.lang.c++.moderated (Why doesn't delete() set pointer to 0?).
>
> Why was delete() defined as delete(void*) instead of delete(void*&)?
The
> latter definition would allow delete() to null the pointer.
>
> Bjarne Stroustrup's has an item about this in his C++ Style and
Technique
> FAQ (http://www.research.att.com/~bs/bs_faq2.html#delete-zero) -- Why
> doesn't delete zero out its operand? -- but the following in that FAQ
> puzzles me.
>
> [...]
> C++ explicitly allows an implementation of delete to zero out an
lvalue
> operand, and I had hoped that implementations would do that, but that
idea
> doesn't seem to have become popular with implementers.
> [...]
>
> How can an implementation zero out the pointer when the pointer is
passed by
> value to delete??

There's two different things involved here: a delete-expression, and
operator delete(). The delete expression is a syntactic construct that
results in a call to the appropriate destructor, followed by a call to
the appropriate operator delete(). The operator delete() function does
not have the right signature to allow changing the pointer passed to
it. However, an implementation could choose to add zeroing-out the
pointer to the effects of an delete-expression.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marcel Loose wrote:
>
> [...]
> C++ explicitly allows an implementation of delete to zero out an lvalue
> operand, and I had hoped that implementations would do that, but that idea
> doesn't seem to have become popular with implementers.
> [...]
>
> How can an implementation zero out the pointer when the pointer is passed by
> value to delete??
>

You are making confusion between operator delete(), which is a function,
and the delete-expression (that is "delete ptr;"), the evaluation of
which *eventually* calls operator delete() but also performs other tasks
such as invoking destructors. The fact the pointer is passed to operator
delete() by-value does not restrict the *delete-expression* to zero out
its argument (if it happens to be an l-value).

HTH,

Alberto

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

* Alberto Barbati:

> You are making confusion between operator delete(), which is a function,
> and the delete-expression (that is "delete ptr;"), the evaluation of
> which *eventually* calls operator delete() but also performs other tasks
> such as invoking destructors. The fact the pointer is passed to operator
> delete() by-value does not restrict the *delete-expression* to zero out
> its argument (if it happens to be an l-value).

This makes me wonder: Is there a way a conforming program could detect
that it has been zeroed, even if it was an rvalue?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Max T. Woodbury" wrote:

> Given the prior distinction between delete operators and delete
> expressions, the main problem with this is that it will lead to a
> false sense of security when the pointer is not the 'owner' of the
> object.  That is when the pointer is a copy of another pointer that
> the programmer thinks of as owning the object.  The current situation
> requires that the programmer provide the additional discipline
> zeroing the pointer would provide and that is more likely to assure
> that the programmer is aware of what is going on.

I don't understand very well what you mean, so I beg your pardon if I am wrong.
Are you saying that, being forced to write two statements instead of one, the
programmer will think more of his pointer semantics? Are you saying that being
forced to write "ptr = 0" after "delete ptr" is "additional discipline"?

I'd say it's just more typing in the keyboard. People are very used to see "ptr
= 0" together with "delete ptr". In fact, I have seen many times preprocessor
macros to delete the pointer and zero it afterwards.

> Automatically
> zeroing the pointer might save a second or two of coding time but
> could easily add hours to the debug time of a program.


This is totally debatable. You will have to show me how explicitally zeroing a
pointer in a point of a program (instead of letting the implementation zero it
for you) makes things better with respect to a dangling pointer to the same
memory somewhere else.
--
Giovanni Bajo

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Giovanni Bajo wrote:
> "Max T. Woodbury" wrote:
>
>>Given the prior distinction between delete operators and delete
>>expressions, the main problem with this is that it will lead to a
>>false sense of security when the pointer is not the 'owner' of the
>>object.  That is when the pointer is a copy of another pointer that
>>the programmer thinks of as owning the object.  The current situation
>>requires that the programmer provide the additional discipline
>>zeroing the pointer would provide and that is more likely to assure
>>that the programmer is aware of what is going on.
>
> I don't understand very well what you mean, so I beg your pardon if I am wrong.
> Are you saying that, being forced to write two statements instead of one, the
> programmer will think more of his pointer semantics? Are you saying that being
> forced to write "ptr = 0" after "delete ptr" is "additional discipline"?

Yes.

> I'd say it's just more typing in the keyboard. People are very used to see "ptr
> = 0" together with "delete ptr". In fact, I have seen many times preprocessor
> macros to delete the pointer and zero it afterwards.

You are entitled to your opinion.  The extra verbiage or use of a macro can
serve as a reminder when debugging that a deleted pointer should not be reused.
It is my experience that debugging is quite a bit more difficult than writing
original code and a little extra thinking about ways to catch bugs while writing
the original code helps.

>>Automatically
>>zeroing the pointer might save a second or two of coding time but
>>could easily add hours to the debug time of a program.
>
> This is totally debatable. You will have to show me how explicitally zeroing a
> pointer in a point of a program (instead of letting the implementation zero it
> for you) makes things better with respect to a dangling pointer to the same
> memory somewhere else.

That is indeed debatable.  That is why I said 'could'.

This is not something that can be 'shown'.  I have simply observed in my
own writing that it does in fact help me.  I expect that it will help some
people and not others.  Having the delete statement zero the pointer can
not assure that the problem you mentioned will be easier to solve because of
the change.  I suspect that it would actually make the problem worse because
some people would come to rely on it producing NULL references in all cases
when in fact that might not happen.  I actually asked myself exactly this
question years ago and concluded that having delete modify the pointer
could, at least in some cases, cause serious problems.  (Actually, I was
thinking about a special version of 'free', but the reasoning works with
delete as well.)  Given that, it made sense to NOT have the delete statement
change the pointer.  The result was a language a little closer to the 'bare
metal' of the machine that could then be 'decorated' with macros or extra
statements as needed.

max@mtew.isa-geek.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marcel Loose wrote:
> Hi,
>
> This is a spin-off question from a question I posted earlier in
> comp.lang.c++.moderated (Why doesn't delete() set pointer to 0?).
>
> Why was delete() defined as delete(void*) instead of delete(void*&)? The
> latter definition would allow delete() to null the pointer.
>
> Bjarne Stroustrup's has an item about this in his C++ Style and Technique
> FAQ (http://www.research.att.com/~bs/bs_faq2.html#delete-zero) -- Why
> doesn't delete zero out its operand? -- but the following in that FAQ
> puzzles me.
>

Given the prior distinction between delete operators and delete expressions,
the main problem with this is that it will lead to a false sense of security
when the pointer is not the 'owner' of the object.  That is when the pointer
is a copy of another pointer that the programmer thinks of as owning the
object.  The current situation requires that the programmer provide the
additional discipline zeroing the pointer would provide and that is more
likely to assure that the programmer is aware of what is going on.
Automatically zeroing the pointer might save a second or two of coding time
but could easily add hours to the debug time of a program.

max@mtew.isa-geek.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Florian Weimer wrote:
> * Alberto Barbati:
>
>> You are making confusion between operator delete(), which is a function,
>> and the delete-expression (that is "delete ptr;"), the evaluation of
>> which *eventually* calls operator delete() but also performs other tasks
>> such as invoking destructors. The fact the pointer is passed to operator
>> delete() by-value does not restrict the *delete-expression* to zero out
>> its argument (if it happens to be an l-value).
>
> This makes me wonder: Is there a way a conforming program could detect
> that it has been zeroed, even if it was an rvalue?

Yes, since pointers are POD:

#include <cstdlib>
#include <iostream>

int main()
{
    char * p = new char;
    char pb[sizeof(char *)];
    std::memcpy(pb, &p, sizeof(char *));
    delete p;
    if (std::memcmp(pb, &p, sizeof(char *)))
        std::cout << "delete modifies pointers\n";
}

--
Ben Hutchings
Humour is the best antidote to reality.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]