Re: C++ PATCH: operator delete[]

[Nathan Sidwell <sidwell at codesourcery dot com>]

Alexandre Oliva wrote:
> 
> On Feb  1, 2000, Nathan Sidwell <nathan@acm.org> wrote:
> 
> > Alexandre Oliva wrote:
> >> On Jan 28, 2000, Nathan Sidwell <nathan@acm.org> wrote:
> > Good point, but I think we're ok. The same condition is applied to
> > operator delete(), so it's safe to pass that a NULL pointer, and it must
> > do nothing with it.
> 
> Well, the *default* operator delete is required to do nothing when
> given a NULL pointer, but a replacement might do something else, and
> calling it in this case would violate the spec of operator delete[].
> Therefore, I propose the following patch.  Ok to install?

Hmm, I think the language of the standard is bad here. The default
behaviour for object and array deletes has different language, but
must essentially mean the same thing.  The required behaviour for
both object and array delete (throw and no throw versions) is to
`accept a value of ptr that is null or that was returned by an earlier
call to [throw or no-throw operator new]'.  Pedantic point, no-throw
new can also return a null pointer.

The badness is that for a null pointer it says `do nothing', which
can be interpretted as `do exactly nothing', or `do nothing at minimum'.
For non-null pointers it must `reclaim the storage'. Again this could
mean `reclaim the storage and do no more', or `reclaim the storage
at minimum'. For the non-null case, we're calling operator delete, and
therefore we can't guarantee `reclaim the storage and do no more', so
we're already interpretting that as `reclaim the storage at minimum'.
(The only way we could guarantee the first is be calling free, which
we've agreed is wrong, and then philisophically how can we guarantee
free doesn't do something more?) So I think we can interpret `do nothing'
as `do nothing at minimum'.

Any user replacement for operator delete(), must be written to accept null
pointers and not go bang -- it might log them or something, but is it
bad?

It makes operator new[] and operator delete[] look asymmetric.

I just don't like this idea of the delete instruction sequence being
a sequence of calls to functions which all start
	bz ptr,exit
	call lower_level_delete
exit:	return
(even with tail call optimization this is still two jumps in a row).
Yeah, micro optimization and all that, sorry :-)

I'll be quiet now.

Of course it's to Jason or Mark comment.

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
Never hand someone a gun unless you are sure where they will point it
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk