Boost logo

Boost :

From: Bjorn.Karlsson_at_[hidden]
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
> criteria.

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, gregod at, cpdaniel at, john at