Boost logo

Boost :

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

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

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