|
Boost : |
From: DKl_at_[hidden]
Date: 2002-04-19 07:24:38
Peter Dimov wrote:
> I've given the intrusive_ptr idea some more thought. It is feasible. My
> questions are:
> * Do we have a consensus that boost needs an intrusive_ptr that is not
> policy based? (IOW is a single variation better than none?)
I doubt that this list will ever get a consensus on anything but if you
settle with a majority rather than consensus, I think this could be
achieved. However, I'm in violent disagreement with naming different
configurations of smart pointers differently: This makes this kind of
variation as evil as policy based pointers are (see the thread on evil
policy-based pointers for more details).
> * How do we decide on the variation? (FWIW the intrusive pointer that I
> use is add_ref/release, no base class requirement, initial value zero,
> self-deleting. I can provide a rationale.)
Personally, I don't care about these details. In fact, I care more about
having a specific smart pointer type appropriate for a given type 'T':
For some types 'T' external counters are appropriate for other types 'T'
intrusive counters are appropriate. *THE* smart pointer should make the
correct choice.
> * Do we need a formal review for intrusive_ptr? (assuming the above
> have been answered.)
I think so.
> The killer feature will be that intrusive_ptr<T>, where
> detail::counted_base is a base class of T, will be implicitly
> convertible to shared_ptr.
The killer feature will be that nobody cares because these types happen
to be identical! Choice is bad (in interfaces). Need for implicit
conversions implies available choices. This is, IMO, the wrong way to
go.
-- <mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/> Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk