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

From: Lee Brown (lee_at_[hidden])
Date: 2002-01-24 17:56:41

On Sunday 20 January 2002 13:51, you wrote:
> From: "AlisdairM" <AlisdairM_at_[hidden]>

> > step backwards for me, as that simplicity is a key part of the design.
> > Likewise, boost::shared_ptr is somewhat more complex, but tending to the
> > simplest possible design for a reference counted pointer suitable for use

> This is a tough call. On one hand. you'd like to benefit of simplicity (so
> that they can actually understand the source code by looking at the source
> code :o)), good error messages, small include file overhead.

Ideally, shouldn't policies _increase_ clarity?  The concept being "turn a 
big problem into many small (easily understood) ones."  I would think that
policies should make the code _clearer_ in some sense.  Although policies 
tend to be abrstractions of specific notions and abstractions are more 
difficult for the human mind to understand,  the code itself should be 
_simpler_.

<IMHO>
Simplicity is essential.  It is a major goal of programming in some sense. 
Complexity creates bugs and impedes reusability. The idea should be to 
program a concept once and only once.  This way reliable structures are built 
on top of reliable structures.  If something is wrong, it is fixed in one 
place. (for example the "for_each" STL function).  I think software should 
strive to only be as complex as the system it is modeling. Like LEGOS.    
</IMHO>

Then again,  I didn't write the book on it.

Lee

> On the other hand however, as the need of functionality increases, the risk
> of source code bloating increases as well. For example, all smart pointers
> share a lot of skeleton code, which as of now is duplicated. Because of
> that approach, you will have to start from scratch and design your own
> pointer whenever you need any behavioral tweak (proprietary reference
> counting, specific checking etc.). So at a point a unified approach becomes
> more attractive because it gives you not only a number of objects, but also
> a framework in which you can define your own.
>
> Loki' SmartPtr class code itself has under 200 lines. It is admittedly
> non-trivial code, but I don't think size puts it in the prohibitive area.
> (By the way, I was thinking of separating various policies in various
> include files.)