Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!bionet!arisia!sgi!shinobu!odin!delrey!shap
From: shap@delrey.sgi.com (Jonathan Shapiro)
Newsgroups: comp.lang.c++
Subject: Re: Change to delete is in order
Message-ID: <5263@odin.SGI.COM>
Date: 14 Mar 90 19:55:04 GMT
References: <5136@odin.SGI.COM> <25FC0210.26173@paris.ics.uci.edu> <3743@tukki.jyu.fi>
Sender: news@odin.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 19

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.

Jon Shapiro
Silicon Graphics