Boost logo

Boost :

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-07 12:56:32

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
Of /course/ I am biased, but I find the approach used by
> SmartPtr using five template template parameters to be much more
> -Dave

But iterator_adaptor also has 7 template parameters (template
template, or regular in noit important IMO). In general it it not
obvious what is better to have SmartPtr parameterized using N Policy
parameters or SmartPtr parameterized with 1 Policies adaptor, which
in turn is constructed from N Policies. FWIW you just adding a level
of indirection. Policies adaptor does do a good job for Policies
communication, but it still questionable how valuable it is. IMO with
good design you would not need a Plicies to communicate. Having
independent policies is much more clear. Each policy is responasable
for separate task and should not try to do what other policy is
doing. StoragePolicy store a pointer, CheckingPalicy validate
pointer. And it is a framework responsability to use them in proper
  Another thing that I wanted to remark is that having SmartPtr to be
inherited from PlicyAdaptor ( or separate policies like in MC++D ) is
brealing encapsulation. Policies IMO are implementation details,
while SmartPtr should define an interface. It does allow us to extent
an SmartPtr interface, but do we want it? Why not to do the same way
iterator_adaptor doing and put Policies object inside of SmartPtr?
could affect a size of it, but iterator_adaptor found a way around.



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