[boost] Re: Bogus smart pointers?

From: Marco Manfredini (marco_at_[hidden])
Date: 2000-03-07 20:15:08

> -----Original Message-----
> From: Miki Jovanovic [mailto:miki_at_[hidden]]
> Sent: Tuesday, March 07, 2000 11:58 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Bogus smart pointers?
>
>
> "marco manfredini" <marc-_at_[hidden]> wrote:
> > Could you point me where that 'call locking' is? I've looked up the
> boost
> > smart-pointer classes from boost.org and did not find anything and
> the issue
> > isn't mentioned in the docs.
> >
> > It all looks like:
> >  T* operator->() const throw() { return px; }
>
> I probably was not clear. We do not call it lock. I was thinking like
> this:
>
>  - to lock means to guarantee object is not deleted
>  - object is not deleted while refCount > 0
>  - refCount > 0 while there is a smart pointer referencing the object
>
> So a simple line like:
>
>  - create another smart pointer to object to be locked
>
> actually does accomplish your task.
>
> In other words, creating another smart pointer to the object, locks it
> for at least the life time of that smart pointer.
>
> To be honest, I do not understand what you are trying to do with your
> applied pointer.

The problems I have with creating another smart-pointer to lock the object
are:

- It is not obligate. Nothing prevents me from using the original 'storing'
smart-pointer which causes the
un-secured 'this' pointer in a call.

- It does not work with scoped_ptr or any other kind of 'one owner' type
pointer. (Either you can't assign or construct from, or ownership is
transferred like in auto_ptr)

- creating an apply pointer uses less resources.

- it conceals the situation

>
> You follow up with a lengthy discussion about a particular system
> design taht encounters these problems. I probably sound too
> simplistic,
> but with the 'locking' mentioned above, and with another rule: caller
> must own the pointer to the callee, I have never faced this problem.
>
> In partucular to your problem: mutuallu calling classes: If class A
> calls class B, it must own the pointer to it. If class B calls A it
> must own the pointer to A. Owning does not mean only owning
> the memory,
> but also to manage access to it.

Exactly that's the Problem here! class Worker called Worker without owning
the pointer to it. It only has a nude 'this' pointer, that was 'borrowed'
from A. But the debt hasn't been fixed, and this caused the trouble. The
current view on smart-pointer classes mixes owning and possesing up. owning
gives you the right to destroy an object, but possesing gives you only the
right to use the object, connected to the liability for the owner (or the
group of owners in case it reference-counting) to guarantee the existence to
the object.

> Finally:
> > apply_scoped_ptr<A> foreign;
> > void doit()
> > {
> >   scoped_ptr<A> sa(new A);
> >   {
> >     apply_scoped_ptr<A> asa(sa);
> >     //use it..
> >   }
> >
> >   scoped_ptr tsa(new A);
> >   sa=tsa; // safe, because no more in use.
>
> >   apply_scoped_ptr<A> asa(sa);
> >   foreign=asa; // foreign has a lifetime that is not a
> subset of sa's
> >   liefetime - this may be a problem! anyway allowed.
> > }
>
> You seem to be missing the point here. If you replaced all of the
> pointers above with smart pointers, you would get *completely* safe
> code. It does not matter how many times you copy it, pass it as a
> parameter or use it otherwise, as long as you have your smart pointer
> to something you can use it.
>

scoped_ptr is a smart pointer and I can not simply replace it with
shared_ptr. If I do so, I can't make the object available to others, without
sharing the ownership - but as an implication of the design it can be
neccesary to an object to have the assertion, that it is the one owner of a
certain other object on a certain moment (for example to free a important
ressource). An "application pointer" concept however would be a interesting
idea, because it could enforce limited forms of ownership (borrowing) and
guarantee, that a certain form of control can be applied to an object in a
given situation.

reset(0); :-)

-Marco