Boost logo

Boost :

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


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

Agreed, there's a cost.

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

I don't know that yet, either.

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

I don't have one. It might not be a real problem.

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

I think you can only do that if the pointer is stored in the policy that
supplies operator->(). Suppose we decomposed the design further, and had a
DereferencePolicy in addition to a StoragePolicy? Actually, this might hint
at a cross-policy interaction.

-Dave


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