[boost] Re: Re: Vertical vs. Lateral Policy implementations

From: David B. Held (dheld_at_[hidden])
Date: 2002-05-01 23:42:15

"David Abrahams" <david.abrahams_at_[hidden]> wrote in message
news:07a601c1f0c9$09d3c210$6401a8c0_at_boostconsulting.com...
>
> From: "David B. Held" <dheld_at_[hidden]>
>
> > "David Abrahams" <david.abrahams_at_[hidden]> wrote in message
> > > From: "David B. Held" <dheld_at_[hidden]>
> > > > Vertical policies facilitate IPC, but at a cost, depending on the
> > > > architecture.  For instance, Beman made a tradeoff between
> > > > straight vertical and straight horizontal policy design (diagonal
> > > > policies?). On the one hand, it simplified the design.  On the
> > > > other hand, it fixed which policies could see each other.
> > >
> > > It doesn't have to. You /can/ leave the ordering up to the user. I
> > > have in mind a "construction kit" where you configure new smart
> > > pointers like this:
> >
> > I must be dense, because I don't see how this is at all similar to
> > Beman's design
>
> Don't see why that makes you dense. I never claimed it was like
> Beman's design.

I misread you as saying that with Beman's design, you can leave the
ordering up to the user.  I see that you were simply saying that with
full vertical policy chaining, you can have any order.  I assumed that
was one of the reasons one would choose vertical chaining.

> > [...]
> > It looks pretty interesting.  I still have a hard time getting my head
> > around the idea of something inheriting from itself.
>
> Nothing can do that in C++.

Well, not directly. ;)

> This is just the straightforward "curiously recursive template" pattern,
> as employed (for example) by the operators library.

Whenever I see people mention it, they seem to call it the "curiously
recurring template pattern", from which I gathered that it pops up in
unusual circumstances.  But I can see that "recurrent" is also a
mathematical term for "recursive", and so the term is a bit
ambiguous.  When you pointed out that it's a *recursive* pattern,
it all made sense.  I don't even want to think about what a compiler
has to do to make that work. :(

> [...]
> If there were base policies which didn't need access to the pointer,
> they could have a default constructor. Maybe the policies don't hold
> the pointer at all, but get passed the entire smart_ptr<> object for
> each operation and extract the pointer explicitly.

Ok.  But when you delegate storage to a policy (a la Loki::SmartPtr),
it seems that you have to have extra c'tors in every policy, right?

> > In mine as well, unless smart_ptr were made to work with, say,
> > shared_ptr, and you started adding all these conversion c'tors
> > that started cluttering up the policies considerably.
>
> You don't put those in the policies. They just live in the outer class.

I see.  I was confused by the fact that you pass a raw pointer to
policy classes.  But with a conversion c'tor, you could just take out
the raw pointer, and pass that down.

> [...]
> > It seems to me that a policy adaptor is a fairly generic idea.
> > Have you considered generalizing it, and making it standalone,
> > so other policy-based designs can take advantage of it?
>
> It's already as general as it can get: it's a design pattern. Anything
> can take advantage of it. Trying to write a generalized policy adaptor
> in code could only make it less general.

True.  But writing anything in code makes it less general. ;)  However,
it seems to me that MPL lets us write something fairly cool.  I.e.:

    namespace detail
    {
        class no_policy_tag;

        template <typename T>
        class no_policy
        {
            typedef no_policy_tag policy_tag;
        };

        class no_defaults
        {
            typedef no_policy_tag default_tag_1;
            typedef no_policy_tag default_tag_2;
            typedef no_policy_tag default_tag_3;
            typedef no_policy_tag default_tag_4;

            template <class>
            class default_policy_1;
            template <class>
            class default_policy_2;
            template <class>
            class default_policy_3;
            template <class>
            class default_policy_4;
        };
    }    // namespace detail

    template
    <
        template <class> class Policy1 = detail::no_policy,
        template <class> class Policy2 = detail::no_policy,
        template <class> class Policy3 = detail::no_policy,
        template <class> class Policy4 = detail::no_policy,
        template <class> class Defaults = detail::no_defaults
    >
    class policy_adaptor
    {
        // MPL pseudo-code
        mpl::typelist policies<Policy1, Policy2, Policy3, Policy4>;

        typedef typename mpl::find_if<policies,
            is_same<
                typename _1::policy_tag,
                typename Defaults::default_tag_1
            >::type
        >::type iter1;
        typedef typename ct_if<
            is_same<iter1, mpl::end<policies>::type>,
            typename Defaults::default_policy_1, Policy1
        >::type policy_1;

        typedef typename mpl::find_if<policies,
            is_same<
                typename _1::policy_tag,
                typename Defaults::default_tag_2
            >::type
        >::type iter2;
        typedef typename ct_if<
            is_same<iter2, mpl::end<policies>::type>,
            typename Defaults::default_policy_2, Policy2
        >::type policy_2;

        typedef typename mpl::find_if<policies,
            is_same<
                typename _1::policy_tag,
                typename Defaults::default_tag_3
            >::type
        >::type iter3;
        typedef typename ct_if<
            is_same<iter3, mpl::end<policies>::type>,
            typename Defaults::default_policy_3, Policy3
        >::type policy_3;

        typedef typename mpl::find_if<policies,
            is_same<
                typename _1::policy_tag,
                typename Defaults::default_tag_4
            >::type
        >::type iter4;
        typedef typename ct_if<
            is_same<iter4, mpl::end<policies>::type>,
            typename Defaults::default_policy_4, Policy4
        >::type policy_4;

    public:
        template <typename T>
        class vertical
            : public policy_4<policy_3<policy_2<policy_1<T> > > > >
        { };

        template <typename T>
        class lateral
            : public policy_1<T>
            , public policy_2<T>
            , public policy_3<T>
            , public policy_4<T>
        { };

        template <typename T>
        class opt_lateral
            : public OptionalInherit<
                OptionalInherit<policy_1<T>, policy_2<T> >,
                OptionalInherit<policy_3<T>, policy_4<T> >,
            >
        { };
    }

Usage:

So this doesn't preserve the order of policy specification, but I'm
sure that could be accomodated if necessary.  And clearly, boost::
preprocessor could be used to scale it.  Surely it's not as general
as the Policy Adaptor concept; but if it fits a wide range of uses,
then it has to be as useful as any other library, no?