[boost] Re: Dangerous smart pointers? (Was: Bogus smart pointers?)

From: Marco Manfredini (marco_at_[hidden])
Date: 2000-03-09 17:27:06

Hi there,

> -----Original Message-----
> From: Miki Jovanovic [mailto:miki_at_[hidden]]
> Sent: Thursday, March 09, 2000 9:26 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Dangerous smart pointers? (Was: Bogus smart
> pointers?)
>
>
> "marco manfredini" <marc-_at_[hidden]> wrote:
> > > If a member function ``commits suicide'' (that is, delete this),
> > > it should understand the consequences.
> > >
> >

// .....

> 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.

This seems to be a misunderstanding. My scenarios didn't pass any explicit
parameters, but only the implict 'this', why is too easily overseen.

>
> 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.
>

If efficiency is a concern, one needs to invest some work, to live with the
restricted completeness of the solution. That's a typical situation.

However, apply_ptr wasn't meant as a simple 'explicit' lock for a member
call, but as an general idea, to make smart pointers more flexible by
reflecting the owner/user relationship. With an apply_ptr, I can for example
return an object that is owned by someone else:

class A
{
 scoped_ptr<X> sp;
 scope_apply_ptr<X> get_it() { return scoped_apply_ptr<X>(sp); }
 //...
};

the returned apply_ptr locks sp during his lifetime. Destroying sp, while
apply_ptr's lock it, gives an runtime-error at the place, where a dangeling
pointers are about to come to life.

Of course, everything could be replaced with share_ptr's, but I've made the
objection, that unrestricted share of ownership can be a problem, if a
certain ressource needs to be freed on a defined moment. Using the approach
above, means that every 'borrowed' pointer to sp is orginated at sp and this
helps to identify problems in the program logic. apply_ptr represents a
"temporary share" that is bound to the lifetime of another object.

The owner/user distiction would also prevent the creation of circular in
many situations:

class Button;
class Window
{ 
 shared_ptr<Button> bu; // controls child
}; 
class Child
{
 shared_apply_ptr<Window> pa; // asks Parent 
}; 

The nice thing is, that the owner/user relationship between Child and Parent is naturally reflected in the kind of pointers they have to each other.

Greetings,

Marco