From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-14 10:05:46
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> The proof is in the pudding, but I'll try to reply in short below.
> > 1. Why the separate Storage and Ownership policies?
> They are orthogonal for the most part. For example, there is no link
> the fact that you allocate a pointer with new and the fact that you
> reference count it. Same pointer allocated with new you also may want to
> reference link (maintain a linked list between all pointers to the same
> object) or simply treat it as an auto_ptr. As far as the ownership policy
> concerned, the managed resource can be allocated anyhow and can actually
> be a pointer at all.
So, the Storage policy says how is the resource (de)allocated, and the
Ownership policy says how is it... what? Copied?
> > 2. How are threading issues addressed? I see RefCountedMT but it doesn't
> > have the proper "template <class> class OwnershipPolicy" signature so it
> > cannot be used, am I missing something?
> That's a bug, thanks for pointing it out. RefCountedMT is not intended to
> customized by the threading model, that's exactly why I used a different
> class name from RefCounted. The history was - initially I wanted to
> implement only one RefCounted class that supports whatever threading
> Then I noticed that I can't customize it the way it needed, so I decided
> write a separate RefCountedMT class. That class is not supposed to support
> different threading models - it just uses the static functions
> AtomicIncrement and AtomicDecrement from ObjectLevelLockable.
> I guess there's a more elegant approach to that, a la
> allocator<T>::bind<U>::other. Or is it more elegant? :o)
Without typedef templates, no. I encountered a similar problem: the
ref_counted policy can be parameterized on the type of the reference count
('long' by default, but the new code uses 'detail::atomic_count'), but this
breaks the template signature.
I suspect we'll have to adopt the 'struct with nested template' approach to
get around this.
> > 3. Why are GetImpl*, Reset, Release free friends and not members?
> See my other post.
Interesting idea, that. It doesn't quite apply to get(); on the other hand
reset() is a prime candidate for a free function since it doesn't need
As for release(), I think that it needs to be dropped.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk