Boost logo

Boost :

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

"David Abrahams" <dave_at_[hidden]> wrote in message
> [...]
> 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?


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