Date: 2002-05-01 03:03:30
> From: Beman Dawes [mailto:bdawes_at_[hidden]]
> * Because user needs are so varied, Standard Library smart
> pointers should
> support a full feature model, including user supplied behavior. A
> policy-based design is seen as the only candidate likely to meet this
It's analogy time:
User needs are varied for containers. Thus, we have list, vector, deque,
set, map etceteras to choose from, all with different performance guarantees
for different operations. This seems like a very reasonable tradeoff, and
although I personally wouldn't mind typing
std::container<std::red_black_tree>, many users would. Of course, this would
tie the interface to the implementation too hard, so I might end up writing
std::logarithmic_time_find...> and so on.
User needs are varied for smart pointers. Thus, we have auto_ptr,
scoped_ptr, scoped_array, shared_ptr, shared_array and weak_ptr for
different behaviors. This seems like a very reasonable tradeoff, and
although I personally wouldn't mind typing (of typedef'ing)
boost::resource_allocated_with_operator_new...>, many users would.
Typedef et al add a protective shield from complexity, and that's indeed a
strong argument - "you can still use shared_ptr (or equivalent) as with the
current interface/implementation in Boost". Sure. At least sometimes. If I
do, the policies will have bought me nothing. If I don't, I've gone beyond
compatibility (type and binary) with those typedef'ed smart pointers anyway.
It's back to roll-your-own, but now with policies rather than the whole
It is (was?) my understanding that Boost.smart_ptr is the most widely used
and most recommended smart pointer library around. Books, magazines,
experts, Boosters, and users; most are endorsing this library, but still it
is being questioned as a suitable addition to the Standard Library?
Oh, by the way, I *really like* the smart_ptr library ;-)
Bjorn "sorry for speaking although I didn't attend" Karlsson
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk