From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-07 14:07:02
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: "rogeeff" <rogeeff_at_m...>
> To: <boost_at_y...>
> Sent: Monday, January 07, 2002 12:56 PM
> Subject: [boost] Re: Loki SmartPtr study: Policy orthogonality
> > --- 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
> > daunting.
> > >
> > > -Dave
> > But iterator_adaptor also has 7 template parameters
> Very true, and it would be much better if it were possible to
> of them (the 5 associated types value, reference, pointer,
> On the other hand:
> 1. They represent very simple ideas that are familiar to anyone who
> learned what a C++ iterator is.
> 2. In many cases the majority will be correct by default and don't
> be supplied.
You still either use default or need to think what to place there.
The same with SmartPtr.
> > Policies adaptor does do a good job for Policies
> > communication, but it still questionable how valuable it is.
> Take a look at how Jeremy applied it in the MTL3 prototype. That's
> convinced me that it was not just a single design, but a valuable
I meant 'how valuable it is for SmartPtr'.
> > IMO with
> > good design you would not need a Plicies to communicate. Having
> > independent policies is much more clear. Each policy is
> > 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
> > manner.
> You may be right. I think much will be clarified when we start
> some actual code.
I still did not hear a real problem/example that could not be
implemented using independent policies. I would be really helpful for
> > Another thing that I wanted to remark is that having SmartPtr
> > 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
> > an SmartPtr interface, but do we want it? Why not to do the same
> > iterator_adaptor doing and put Policies object inside of SmartPtr?
> > could affect a size of it, but iterator_adaptor found a way
> I've been thinking about that one, too. I think the advantage of
> approach is that in addition to extending the interface, you can
> the interface of the outer smart pointer by refusing to supply
> interface elements in your policies. With an approach like that of
> iterator_adaptor, you can do that to some extent by selectively
> compile errors inside the Policy operations, but the error messages
> as good. Wouldn't you rather see something like:
> file, line: no operator ->() defined for boost::smart_ptr<....>
> than some kind of static assertion failure?
If policy does not implement some of the interface methods it still
will be a compilation error like this:
file, line: no operator ->() defined for MyOwnStoragePolicy<...> ...
Even without static asserts.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk