Boost logo

Boost :

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.


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