Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!samsung!munnari.oz.au!sharam@munnari.oz.au
From: sharam@munnari.oz.au (Sharam Hekmatpour)
Newsgroups: comp.lang.c++
Subject: Re: Change to delete is in order
Message-ID: <3363@munnari.oz.au>
Date: 16 Mar 90 06:51:14 GMT
References: <5136@odin.SGI.COM>
Sender: news@cs.mu.oz.au
Reply-To: sharam@munnari.oz.au
Lines: 39

From article <5136@odin.SGI.COM>, by shap@delrey.sgi.com (Jonathan Shapiro):

> 	delete should be defined to zero the pointer it is handed
> 	after freeing the associated store.

I agree with you. A few people have pointed out that this causes problems
when the operand of delete is not an lvalue. They are WRONG. Let me
explain why...

The case that the operand is *not* an lvalue can be handled by, for
example, ensuring that a *copy* of the pointer is zeroed instead
(as if no zeroing has taken place). This is perfectly safe.

Using references, implementing this in C++ is very easy:

	inline void
	zelete (void*& ptr)	// Zero after dELETE
	{
		delete ptr;
		ptr = 0;
	}

Now suppose p and q+10 point to valid blocks created by new:

	zelete(p);	// deletes and zeros p
	zelete(q+10);	// deletes but does not zero q+10

In the latter case, because the formal argument is a reference, the
actual argument is treated as a value; hence ptr receives a *copy* of
q+10 and zeros that! So non-lvalues are treated properly.

Aside, it is a shame that this cannot be achieved by globally overloading
delete, since we will end up with infinite recursion. Defining it as a
function having a different name (as I've done here) is just about the
neatest way I can think of right now.

Regards,

Sharam Hekmatpour