"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > That's OK if the class which ultimately takes posession of p (not > base_type, I think, but storage... or is it ownership?) is _required_ > to take it by reference. Does such a requirement exist?
It does now. ;) For the most common cases, it isn't a problem, obviously, because p will be fundamental. For smart-resource type applications, I still have a hard time imagining that you would want to write a storage policy that takes a *copy* of a managed resource, rather than the *actual resource*. However, I will make it explicitly clear in the docs that if you take a copy, and it throws, you will probably leak your resource. > [...] > That is a very clean approach, and assuming it's OK to keep the > the sole copy of p in storage_policy, even efficient. I'm not sure anyone would use a pointer that kept multiple copies of p. Wouldn't that make it pretty fat? > > [...] > > Ownership may have state, but but it need only be consulted > > when the resource could possibly be shared or moved. That's > > only possible if the smart_ptr c'tor has completed. > > I'm not sure that's true for intrusively-counted types. Ouch. This is a serious problem that requires some thought. Dave _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
