Boost logo

Boost :

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 {

>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

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;

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at