Re: [boost] Loki SmartPtr study: Policy orthogonality issues

From: Lee Brown (lee_at_[hidden])
Date: 2002-01-12 20:09:01

>Of /course/ I am biased, but I find the approach used by
>SmartPtr using five template template parameters to be much more daunting.

How about something less confusing.

struct default_policy_policy {
        typedef default_construct_policy  construct_policy;
        typedef default_copy_policy copy_policy;
        typedef default_destruct_policy destruct_policy;
        typedef default_assign_policy assign_policy;
};

typedef generic<default_policy_policy> default_generic;

template<class PolicyPolicy>
class generic {
public:
...
};

>In general it it not
>obvious what is better to have SmartPtr parameterized using N Policy
>parameters or SmartPtr parameterized with 1 Policies adaptor, which
>in turn is constructed from N Policies. FWIW you just adding a level
>of indirection.

With indirection comes generality. In this case the generality
comes at compile time.  This also addresses some of the policy communication 
details.

template<class CheckingPolicy>
struct check_policy_policy {
        typedef CheckingPolicy checking_policy;

        typedef check_construct<checking_policy> construct_policy;
        typedef check_destruct<checking_policy> destruct_policy;

        typedef default_copy_policy copy_policy;
        typedef default_assign_policy assign_policy;
};

perhaps we want to make construct/destruct "consistent".

struct con_des_policy {
        typedef new_cons_policy construct_policy;
        typedef delete_des_policy destruct_policy;
};

template<ConDesPolicy>
struct con_des_policy_policy {
        typedef ConDesPolicy con_des_policy ;

        typedef typename con_des_policy::construct_policy construct_policy;
        typedef typename con_des_policy::destruct_policy destruct_policy;

        typedef default_copy_policy copy_policy;
        typedef default_assign_policy assign_policy;
};

I imagine the combinations are endless.  Now the novice programmer can be
exposed to consistent policy groups, while the advanced programmers develope
the consistent groups.

>Practically every programmer uses "simplified" interfaces to many kinds of
>complex systems all the time.

didn't einstein say our understanding of things should be as simple as 
possible
but no simpler.

>I think that some of us will follow the discussion much more easily if it
>includes some minimal but compilable examples that illustrate the point.

FWIW: I agree.

>Policies IMO are implementation details,
> while SmartPtr should define an interface.

FWIW: I agree. I can give code as to why as well.