Re: [boost] Re: Loki SmartPtr study: Policy orthogonality issues

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-07 13:51:13

----- Original Message -----
From: "rogeeff" <rogeeff_at_[hidden]>
To: <boost_at_[hidden]>
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.

I think that in retrospect it might have been possible to avoid having so
many extra parameters, by incorporating associated type generation into the
policies as Andrei has.

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

The issue that motivated my suggestion was that Beman was trying to figure
out how to easily enable differnt aspects of the SmartPtr's policies to
interact. Making this happen is easier when you have a single policies
class, which can be formulated any way you like.

> FWIW you just adding a level
> of indirection.

Don't knock it; someone once said that every problem in computer science can
be solved that way ;-)

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

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

>   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?

-Dave