Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-29 19:54:23

"David B. Held" <dheld_at_[hidden]> writes:

> I suppose we could do something like this:
>
>     void scalar_storage::acquire(stored_type const& p)
>     {
>         pointee_ = p;
>     }
>
>     template <typename U>
>     void ref_counted::acquire(U const& p)
>     {
>     }
>
>     template <typename U>
>     smart_ptr(U const& p)
>     {
>         try
>         {
>             storage_policy::acquire(p);
>             ownership_policy::aquire(p);
>             checking_policy::on_init(get_impl(*this));
>         }
>         catch (...)
>         {
>             storage_policy::destroy();
>             throw;
>         }
>     }
>
> Ultimately, it's only slightly less efficient than the initializer list
> form, and
> now doesn't leak p when someone passes 'new X'. 

It sure does if any of the bases or members of smart_ptr throws from
its constructor.

> Orthogonality is preserved, and angels from on high sing Hallelujah
> (ok, maybe the last part is stretching it).  Taking ownership
> probably should be a separate step from construction anyway.

I dunno.  Acquiring ownership at construction time is a key part of
the "one true meaning" of RAII (not the accepted meaning, which has
come to be "deallocating resources in destructors" -- a concept having
nothing to do with acquisition _or_ initialization).  There's a good
reason for this, since it avoids the problem of leaking when a
constructor throws.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution