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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-18 09:04:50

From: "David Abrahams" <david.abrahams_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
>
> > > struct Base { Base(); ~Base(); };
> > > struct Derived : Base { Derived(); ~Derived(); };
> > >
> > > void unsafe()
> > > {
> > >      shared_ptr<Base> b(new Derived);
> >
> > The expression "delete get()" invokes undefined behavior, therefore the
> code
> > is ill-formed.
>
> 1.3.14 well-formed program
> a C++ program constructed according to the syntax rules, diagnosable
> semantic rules, and the One Defini-
> tion Rule (3.2).
>
> So, I think "buggy" would be a better term here ;-)

OK, "ill-formed, no diagnostic required." Or "the behavior is undefined."

> This is one reason I think it should be possible to configure a shared_ptr
> so that it can't be constructed from a raw pointer. Here's another:
>
>     shared_ptr<X> p(new X);
>     f(p.get());
>
>     void f(X* p)
>     {
>         shared_ptr<X> y(p); // double-deletion
>     }
>
> I've seen this mistake made by novices and experts alike.
> Instead, there ought to be a family of static factory functions, so:
>
>    shared_ptr<Y> p = shared_ptr<Y>::create(arg1, arg2, arg3);
>
> is equivalent to:
>
>     shred_ptr<Y> p(new Y(arg1, arg2, arg3));

Strongly agreed; I often say that new/delete have no place in user code. Now
if you have a solution handy for the argument forwarding problem, that'd be
great. ;-) (Note: it's not 4^n, it's 2^n, and it doesn't work.)

--
Peter Dimov
Multi Media Ltd.