Re: [boost] Why are we looking for a boost/Loki smart-pointer merginf?

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.