Boost logo

Boost :

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);
 void doit()

_ptr<A> some_A(new A);

void Worker::work()

void main()

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

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
Workarounds are possible, but they all look very error prone to me.


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? is your complete source for party planning and
supplies, with everything you need to throw the perfect party!

-- Create a poll/survey for your group!

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