Re: Loki SmartPtr study: Policy orthogonality issues

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 
issues
> 
> 
> > --- 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 
eliminate most
> of them (the 5 associated types value, reference, pointer,
> iterator_category).
> 
> On the other hand:
> 
> 1. They represent very simple ideas that are familiar to anyone who 
has
> learned what a C++ iterator is.
> 
> 2. In many cases the majority will be correct by default and don't 
have to
> 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 
what
> convinced me that it was not just a single design, but a valuable 
idiom.

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 
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
> > manner.
> 
> You may be right. I think much will be clarified when we start 
looking at
> 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 
discussion.

> 
> >   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.
> 
> I've been thinking about that one, too. I think the advantage of 
Andrei's
> approach is that in addition to extending the interface, you can 
also limit
> the interface of the outer smart pointer by refusing to supply 
certain
> interface elements in your policies. With an approach like that of
> iterator_adaptor, you can do that to some extent by selectively 
causing
> compile errors inside the Policy operations, but the error messages 
aren't
> 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.

> 
> -Dave

Gennadiy.