[boost] Re: Bogus smart pointers?

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-03-07 16:58:59

A rather insulting subject line but ...

You are correct that there is no way to guard against abuse of
the "this" pointer with shared_ptr, scoped_ptr, or auto_ptr.
I would be interested in how your experiments with using a
temporary to bump the count during a call work out.

----- Original Message -----
From: Marco Manfredini <marco_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, March 07, 2000 2:07 AM
Subject: [boost] Bogus smart pointers?

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 :-)

------------------------------------------------------------------------
Planning a party? iParty.com is your complete source for party planning and
supplies, with everything you need to throw the perfect party!
http://click.egroups.com/1/1635/1/_/9351/_/952420059/

-- Create a poll/survey for your group!
-- http://www.egroups.com/vote?listname=boost&m=1