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

From: Miki Jovanovic (miki_at_[hidden])
Date: 2000-03-10 11:14:56

"marco manfredini" <marc-_at_[hidden]> wrote: 
> This seems to be a misunderstanding. My scenarios didn't pass any
explicit
> parameters, but only the implict 'this', why is too easily overseen.

I never said it had to be explicit. 'this' is a parameter, sure
implicit but it must be treated the same way. To be honest, I never
think of 'this' as a parameter, but I do think explicitly about the
lifetime of the current object, and what it can do safely and what it
cannot.

As for the overseen bit... I would argue that it is just as easy to
forget to lock 'this'. 

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

Well this is a good point. However this sounds quite a lot like a debug
time assert. I have nothing against having a check like this. But I
will argue strongly against a debugging tool changing the logic or
structure of my code. If we can find a way to establish a check like
this and make it not intrusive to the overall system, I am ready to put
my vote for it.

> 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 
> }; 

OK, OK... You might be getting through to me here... 'shared_apply_ptr'
is actually a dumb pointer which registers its interest in an object.
So *_apply_ptr does not regulate the lifetime of the object, but rather
only a check so an error can be raised if the object is being destroyed
while still in use by *_apply_ptr.

OK, if apply_ptr is a straight replacement for a dumb pointer with an
additional safety check, then this is probably a solution that would
satisfy my 'non intrusive' criteria. So is my interpretation right?

BTW, if my interpretation is right, then I have a big problem with the
name. 'apply' is not suggestive of its use at all. 'borrowed_ptr',
'dumb_ptr' just quick suggestions. I am sure somebody will think of a
good name.

Cheers,

Miki.