[boost] Bogus smart pointers?

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

Hello Boosters

I have a question regarding the safety of the (memory management related)
smart-pointer classes in discussion:

What is the supposed strategy to handle the escape of the 'this' pointer
during a call?

Here an example:

class Worker
{
 virtual void work_out() {}
 virtual void work();
};

class A
{
 _ptr<Worker> w; // _ptr is an arbitrary smart_pointer that maintains the
ownership, a reference couting sp for example.
 A() : w(new Worker) {} // here it is

 // just aa example, leads to reallocation
 void update()
 {
         _ptr<Worker> n(new Worker);
         w=n;
 }
 void doit()
 {
         w->work();
 }
};

_ptr<A> some_A(new A);

void Worker::work()
{
        some_A->upgrade();
        work_out();
}

void main()
{
        some_A->doit();
}

After the construction some_A->w holds 1 reference to a Worker object.
main() calls A::doit(), which calls work() for that Worker, which in turn
calls
upgrade().
Now upgrade replaces the current Worker with a new one and returns...into
the Worker
object which has been deleted 1 µSec ago. For demonstrational purposes only,
the Worker zombie calls
work_out, which doesn't work out.
This can also happen without the use of smart pointer classes, but I want
them to protect me against my belief in *ownership*: I simply
have overseen, that I *borrowed* the pointer to the stack.

I've looked at the smart-pointer classes in boost, but I found no provisions
to guard the 'this' Pointer that lurks
around during a call. However, the pattern I am describing is to be expected
in complex object interactions and
will produce these randomly appearing bugs, that shorten a developers
lifespan.

A -transparent- solution is to create an extra lock during a call. (i.e
operator-> returns a temporary): This has implications to
the performance of the various pointer classes, which need to be
investigated.
Workarounds are possible, but they all look very error prone to me.

-Marco

P.S. AFAIK: The Microsoft _com_ptr_t "native Compiler Support" reference
counting smart pointer class also ignores this problem.
        I think this explains everything :-)