Boost logo

Boost :

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

Why? if interface between Framework and Policy is different than you
will see something like this:

file, line: no method dereference() defined for
MyOwnStoragePolicy<...> ...

> Suppose we decomposed the design further, and had a
> DereferencePolicy in addition to a StoragePolicy? Actually, this
might hint
> 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.

Gennadiy.

>
> -Dave


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