Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!jarthur!uci-ics!rfg
From: rfg@ics.uci.edu (Ronald Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: Change to delete is in order
Message-ID: <260349F1.24972@paris.ics.uci.edu>
Date: 18 Mar 90 08:42:25 GMT
References: <5136@odin.SGI.COM> <25FC0210.26173@paris.ics.uci.edu> <3743@tukki.jyu.fi> <5263@odin.SGI.COM>
Reply-To: rfg@ics.uci.edu (Ronald Guilmette)
Organization: UC Irvine Department of ICS
Lines: 34

In article <5263@odin.SGI.COM> shap@delrey.sgi.com (Jonathan Shapiro) writes:
>In article <3743@tukki.jyu.fi> sakkinen@jytko.jyu.fi (Markku Sakkinen) writes:
>>
>>Shapiro's proposal is nevertheless sensible, and would make 'new' and
>>'delete' more symmetric.  The zeroing could be done _if_ the operand
>>is an lvalue. For a redefined delete operator, this could be done
>>_before_ it is actually invoked, but after the destructor (if any)
>>is invoked.
>
>All I wanted was a definition that helped debugging on many systems if
>it wasn't incorrect.  Enough people have pointed out that rvalues make
>it a problem that I am forced to conclude that it isn't correct and
>shouldn't be part of the language definition.
>
>It might still be worth an implementation note to encourage compiler
>authors to generate pre-optimized code that zeroes the pointer iff it
>is an lvalue in the interest of debugging.

Now I think that you are on to a very good idea here!

It would certainly be nice if the language definition were to say that:
"In cases where the expression given in a delete statement is an lvalue,
the value of that lvalue after the execution of the delete statement is
undefined."

A rule like that would allow (but not require) the zeroing of lvalue
pointers given in delete statements.  Implementors could then choose
if they wanted to do the zeroing for the sake of slightly better
debugability.


// Ron Guilmette (rfg@ics.uci.edu)
// C++ Entomologist
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.