Boost logo

Boost :

From: Lee Brown (lee_at_[hidden])
Date: 2002-01-26 05:02:17

> In what way does introducing policies and abstraction simplify and clarify
> the boost::scoped_ptr. The task of this class is incredibly simply, is a
> single well-defined abstraction in its own right, and doesn't need
> confusing with a lot of policies and extra concepts that are irrelevent to
> it. *unnecessary* abstraction is a great way to obfuscate code.

Yes. I've experimented with this smart pointer business quite a bit over the
past few days. From my short experience, I've noticed a couple of things. It
seems the best way to start out is to make a concrete common case class i.e.
like scoped_ptr. Then generalize as it is neccessary or helpful.

Templates tend to be helpful whenever a choice of type is unknown or
undecided. That is, there is more than one type that could be conceived as
being a data member. I think of normal templates as being more data-centric.

Policies strike me as being drop-in replacements for functions. For some
reason, I can't help feeling that policy classes make the most sense when all
public members of a policy class are static functions. If a policy class has
normal members then it loses its drop-in replaceability.(see stroustrup ed.3
chap 13.4).

In short, these abtractions are useful when a) you are doing something over
and over again for different data types b) You want functionality but are not
quite sure (at the time) which is the best way to go.

Yes. you are right. Evolutionary is better than revolutionary.

BTW: I've attached a short implementation of a smart_ptr. It does use
policies but is very close in appearence to what boost currently has, but
with perhaps a little more flexibiltiy. If anyone wants to comment I would
like to hear it, even if you aren't particularly nice about it. Its off the
top of my so there may be errors.

Boost list run by bdawes at, gregod at, cpdaniel at, john at