Boost logo

Boost :

From: Miki Jovanovic (miki_at_[hidden])
Date: 2000-03-09 15:25:50


"marco manfredini" <marc-_at_[hidden]> wrote:
> > If a member function ``commits suicide'' (that is, delete this),
> > it should understand the consequences.
> >
>
> The member function wasn't commiting suicide. The member called code,
that
> killed an active object. In "reality" it means, an member calls code,
that
> calls code, that calls code...that kills an active object. And that's
a
> problem that can't be adresses with scoped_ptr yet. Making a
temporary is a
> workaround, but it hides the motivation for the temporary -- and
hiding the
> motivation to do something is one path to sloppyness.
> Anyway: everyone in the example played by the rules and troubles came
from
> the fact, that the user of an object is not always the owner.

I beg your pardon. I believe you are wrong here. In your scenario, A
calls B with parameter ptr. B calls A back, and here A deletes ptr.
This broke the basic rule that the we were quoting. A does not
guarantee that the parameter ptr is valid while B is executing. And
this is plain wrong. Details how you guarantee this are up to you
(temporary, apply_ptr, any way) but it has to be done.

The way I deal with this is to design modules that use callbacks like
this differently then the other code. So the callback-enabled code has
extra safeties to guard against this thing.

In the same time, the rest of the code using smart pointers is not
burdoned with the complexity of locking/lockable pointers.

Cheers,

Miki.


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