Boost logo

Boost :

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-25 08:53:05


From: Lee Brown [SMTP:lee_at_[hidden]]
>
> 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

Since a policy class groups potentially independent concepts together,
forming an entity that you can study, manipulate, and recognize, yes, they
should make the code clearer.

> tend to be abrstractions of specific notions and abstractions are more
> difficult for the human mind to understand, the code itself should be

Huh? We create abstractions expressly to make things easier to deal with.
Some have posited that the human mind can only deal with 7-9 things at once.
In order to deal with a more complicated system, one must work in terms of
abstractions. By glossing over details and working with abstractions, one
can wield great power over complex systems. This is the power of policies.

WRT smart pointer design, I suggest that there needn't be an all or nothing
approach. Not all of the current facets of Loki::SmartPtr need to be
grouped into a single policy class. Perhaps there are some that are and
always will be -- until the next refactoring shows the error of our ways! --
independent. In that case, the potentially interconnected aspects can be
grouped in a policy class, and the independent aspects can remain separate
template parameters. Then again, that may just confuse the issue.

Rob
Susquehanna International Group, LLP
http://www.sig.com


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk