Re: [boost] Loki SmartPtr questions

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
between
> 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
is
> concerned, the managed resource can be allocated anyhow and can actually
not
> 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
be
> 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
model.
> Then I noticed that I can't customize it the way it needed, so I decided
to
> 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
friendship.

As for release(), I think that it needs to be dropped.

--
Peter Dimov
Multi Media Ltd.