Boost logo

Boost :

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

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.

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


> 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.)

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