Re: [boost] Re: shared_ptr: unsafe, or am I crazy?

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2002-01-18 14:54:27

> From: "Thomas Maeder" <maeder_at_[hidden]>
> > Am 2002.01.18 14:40 schrieb(en) Peter Dimov:
> > > The original example was:
> > >
> > > shared_ptr<Derived> d(new Derived);
> > > shared_ptr<Base> b(d);
> > > d.reset();
> > > b.reset();
> > >
> > > Which line invokes the undefined behavior? My answer is "none of them"
> > > and therefore I have implemented a version of shared_ptr that handles the
> > > example fine.
> >
> > My answer is: The second one.
> 
> Possible, but inconvenient. There is no good reason to introduce undefined
> behavior here. Consider:
> 
> shared_ptr<Derived> d(new Derived);
> shared_ptr<Base> b(d);
> b.reset();
> d.reset();
> 
> The second line is the same but it now works (with the current
> implementation.)

shared_ptr<T> x(0);
if (&*x) {
  x->foo();
}

This also works on current C++ implementations (all the ones I know 
about anyway). Nevertheless, this behavior is still undefined, and for 
good reason.

So why not for the previous case?

As has been pointed out elsewhere, this is not necessarily a problem 
for the destructor only, it is a more general problem when upcasting 
classes which overload base class functions non-virtually. The 
destructor is certainly the most common case, of course.

IMHO this is NAD; this is one of the things C++ programmers are 
supposed to know about and understand when designing class hierarchies. 
I don't like adding the extra layer of indirection for *all* shared_ptr 
destructor calls, in order to 'solve' this, for the destructor case 
only. In a policy-based smart pointer, I would support making it an 
available policy but not the default one.

George Heintzelman
georgeh_at_[hidden]