[boost] Re: SmartPtr - Exception safety reprise

From: David B. Held (dheld_at_[hidden])
Date: 2003-02-01 16:57:42

"David Abrahams" <dave_at_[hidden]> wrote in message
news:uznpfkfhe.fsf_at_boost-consulting.com...
> [...]
>   C) Make sure the first base class of smart_ptr is the one that
>      manages destruction of its resources:
>
>   template <class Storage, class Ownership>
>   struct ptr_manager
>      : Storage, Ownership
>   {
>      ptr_manager(ptr_manager const& p) : Storage(p), Ownership(p) {}
>
>      ~ptr_manager()
>      {
>          if (!this->Ownership::release(get_impl(*this)))
>          {
>              this->Storage::release();
>          }
>       }
>   };
>
>    smart_ptr::smart_ptr(smart_ptr const& rhs)
>       : ptr_manager(rhs), checking(rhs), conversion(rhs)
>    { checking::on_init(p); }

I was actually thinking in this direction somewhat.  I did notice that it
really is the smart_ptr d'tor that really knows how to properly clean
stuff up, and it should probably be the one to do so.  This might be
the way to go.

> [...]
> I think that whatever orthogonal concepts are being represented
> by ownership and storage here (and I'm really not sure I see a
> clear separation), they must be sub-concepts of what is normally
> referred to as ownership.  You can see that from the fact that you
> need a sub-object to group them together to handle resource
> lifetime correctly.  I would explore/discuss the implications of not
> separating ownership and storage to see whether it's buying you
> more than it's costing.

There are several cases where it's clear that storage and ownership
aren't the same thing.  First, is scalar_storage vs. array_storage.
Second, is pointer vs. other resource.  Pointers to arrays benefit
from all of the ownership strategies provided by SmartPtr that
pointers to objects enjoy.  A smart resource can certainly make
use of ref-counting, deep copy, no-copy, and move semantics.  I
think it's clear that with respect to these ideas, storage and ownership
are indeed orthogonal.  Merging them would evoke a combinatorial
explosion of the nature hinted at by scoped_ptr, shared_ptr,
scoped_array, shared_array, (scoped_resource, shared_resource,
deep_ptr, deep_array, deep_resource, intrustive_ptr,
intrusive_resource, com_ptr, com_resource, etc.).

It's unfortunate that they must interact, but I do believe that they are
orthogonal in principle.  However, your intermediate class might be
the most appropriate decomposition.  I'm leaning towards that
pending further insight/analysis.

> BTW, I don't want to beat this to death, but addressing the issue
> of most compilers not doing the EBO for anything other than the
> first base class has a huge bearing on all of this,

Well, I want to at least give the VC++ guys a few days to see if
they say anything.  I posted a question on a M$ newsgroup.  I
think I did the first time around, too, and they didn't.  It would be
really cool if, say, Jason Shirk offered some insight, or at least
knocked some skulls so we got *some* kind of answer, even if
it's "there's no way in heck we will give out that kind of
information".  At least then I could give up hope, and we could
fully enter the tedious debate over alternatives.  But there must
be *someone* on the VC++ compiler team that wrote the EBO
code, and if it were me, I'd have enough pride to at least say
when I know that it *does* work (and it does work for some
MI...optimally_inherit was doing its job until the latest round of
changes).  Bueller?  Bueller?  Bueller?

Dave