Boost logo

Boost :

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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at