[boost] Re: policy-based smart pointers are EVIL! (was: Intrusive smart pointer)

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-04-19 20:01:09

"Douglas Gregor" <gregod_at_[hidden]> wrote in message
[snip]
> But suppose that you didn't need to configure smart_ptr individually for
each
> type. Would you then agree with the premise, that the type of reference
> counting is almost always dependent on 'T' for 'smart_ptr<T>'?

Yes. Better said, it is almost always dependent on the hierarchy that T
belongs to.

However, as I showed in the Widget amd multithreading example in my other
post, there are realistic, convincing situations in which you do want to use
different policies for the same type. Given that policies are inherently
more flexible than traits, they are the obvious choice.

> If I have a type T with intrusive reference counting, I would expect
> shared_ptr<T> to use that intrusive reference counting. If T is an open
FILE,
> I expect shared_ptr<T> to have an external reference count and know how to
> fclose() the file when the count drops to zero. Having to specify the
policy
> along with the type _seems_ like it could be error-prone. If I'm supposed
to
> use 'smart_ptr<MyCOMObject, COMRefCountPolicy>' and I accidentally type
> 'smart_ptr<MyCOMObject>', bad things will happen.

I agree.

> But nobody wants to specialize a smart_ptr_traits for every single class.

Fortunately you can do that for a whole hierarchy. What a neat language
ain't it :o).

> However, reference counting is a property that is always inherited by
derived
> classes. We could massage the type traits notion a little so that we use
> overloading instead of partial specialization:
[snip]

I think hierarchy-wide traits are a simpler solution.

Andrei