From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-07 15:37:57
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > > 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
> > > iterator_adaptor, you can do that to some extent by selectively
> > causing
> > > compile errors inside the Policy operations, but the error
> > aren't
> > > as good. Wouldn't you rather see something like:
> > >
> > > file, line: no operator ->() defined for
> > >
> > > than some kind of static assertion failure?
> > If policy does not implement some of the interface methods it
> > will be a compilation error like this:
> > file, line: no operator ->() defined for
> > Even without static asserts.
> I think you can only do that if the pointer is stored in the policy
> supplies operator->().
Why? if interface between Framework and Policy is different than you
will see something like this:
file, line: no method dereference() defined for
> Suppose we decomposed the design further, and had a
> DereferencePolicy in addition to a StoragePolicy? Actually, this
> at a cross-policy interaction.
That's the key! No need to decompress the things that are naturally
come together. If you need, you can parameterize StoragePolicy with
another template parameter but StoragePolicy still should solid and
present the appropriate interface to the framework.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk