"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
