Boost logo

Boost :

Subject: Re: [boost] deleting smart pointer
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-03-20 18:23:34


AMDG

On 03/20/2011 02:30 AM, pavel wrote:
> Steven wrote on Saturday, March 19, 2011 at 18:40:26:
>> Actually, I got it from n3242 which is a recent C++0x draft.
> are you sure that this draft is going to become the final version of
> std?

Nope. It definitely will get some more updates.
However, I think it highly unlikely that this restriction
will be removed. It already existed for array delete,
and this makes the two more consistent.

>> "In the first alternative (delete object), if the static type
>> of the operand is different from its dynamic type, the
>> static type shall be a base class of the operand’s
>> dynamic type and the static type shall have a virtual
>> destructor or the behavior is undefined."
> i believe this part concerns slicing as when one deletes an object of
> some derived class D using pointer to the base class B
>
> this way ~D() destructor has no chance to be executed and we have the
> whole bunch of unwanted effects
>
> furthermore when '::delete operator()' function is called the compiler
> may miscalculate the size of the object to be deleted since sizeof(D)
> may differ from sizeof(B) and the deallocation function likely be
> supplied with wrong size argument which again may cause unexpected
> effects
>
> in my variant of implementation all destructors involved are trivial
> (read: they are never called)

Not guaranteed.

> and the global deallocation function
> ('::operator delete()') is never called on the operand of the delete
> expression

Irrelevant.

> so i believe it shouldn't cause undefined behavior anyway

Undefined behaviour does not mean that the
code will do bad things. It means that the
standard does not specify what happens.

Don't try to second guess the implementation
like this. Just because you can't think of anything
that can go wrong, does not mean that it's safe.

In Christ,
Steven Watanabe


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk