RE: [boost] Re: [mpl] Advice on usage

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-10-09 02:57:53

David B. Held wrote:
> > Fixing a missing typename
> 
> Technically, my version wasn't missing a typename, because I was using
> is_same<>::value with if_c. ;)

And I wasn't referring to that one :). 

        typedef typename mpl::if_c<
            ::boost::is_same<i_, mpl::end<Sequence>::type >::value,
                                 ^^^^^^^^^^^^^^^^^^^^^^^^
            make_iterator<Default>, i_
        >::type::type type;

> 
> > and style a little bit, here's an "approved" version :)
> 
> But I do like your version better.  Thanks for the tip.  I 
> see that apply_if combines an if_ with a dereference, which happens 
> to be the same as an apply.  I wouldn't have figured that out on my own.
;) 

http://www.mywikinet.com/mpl/#applyif, the last paragraph:

"The described technique is so common in template metaprograms, that it
makes sense to facilitate the selection of the nested type member by
introducing a high level equivalent to if_ that will do func_::type
operation as a part of its invocation. The MPL provides such a template -
it's called apply_if. ..."

> Now, I notice that you don't bother to hide "private metavariables", 
> but just make everything struct.  Is that simply because it would be silly
to 
> try to use any of the the intermediate results, and thus there's no point
to 
> try to hide any of the implementation details?

In the library code, I usually do hide auxiliary typedefs declared directly
in the scope of a public component:

    template< typename T > struct my_algorithm
    {
     private:
        typedef /* ... */ iter_;
        typedef /* ... */ last_;
     
     public:
        typedef /* ... */ type;
    };

to denote even more explicitly that members with '_' suffix do not comprise
a public interface. I usually don't bother with it in the scope of
implementation structs:

    namespace aux {
    template< typename T > struct my_impl
    {
        typedef /* ... */ iter_;
        typedef /* ... */ last_;
        typedef /* ... */ type;
    };
    }

    // often defined in a separate header
    template< typename T > struct my_algorithm
        : aux::my_impl<T>
    {
    };

mostly because I am lazy ;).

> 
> > [...]
> > A question - why BOOST_STORAGE_POLICY et al. instead of, let's say,
> >
> >     typename get_storage_policy<policies_,T>::type
> >
> > ?
> 
> Good question.  Two reasons.  One, repetition.  They appear twice, and
> something as complex as this isn't something I want to spend time on
> synchronizing whenever I make a minor change (this is the 
> kind of thing I'd spend an hour on diagnosing). 

But from maintenance point of view the difference between

# define BOOST_STORAGE_POLICY \
    apply_lambda< \
        get_policy<policies_, storage_policy_tag, scalar_storage<_> >::type,
\
        T \
    >::type

...
    class smart_ptr
        : public optimally_inherit<
            optimally_inherit<
                  BOOST_STORAGE_POLICY
...
    {
    public:     // Policy types
        typedef T                       element_type;
        typedef BOOST_STORAGE_POLICY    storage_policy;

and

    namespace aux {
    template< typename Policies, typename T >
    struct storage_policy
    {
        typedef typename get_policy<
              policies_
            , storage_policy_tag
            , scalar_storage<_>
            >::type f_;
            
        typedef typename apply_lambda<f_,T>::type type;
    };
    }

...
    class smart_ptr
        : public optimally_inherit<
            optimally_inherit<
                  typename aux::storage_policy<policies_,T>::type
...
    {
    public:     // Policy types
        typedef T element_type;
        typedef typename aux::storage_policy<policies_,T>::type
storage_policy;

is negligible, IMO (ignoring the fact that BOOST_STORAGE_POLICY is a macro
:).

> Two, what I didn't show is the template template version (which I left in 
> for historical reasons).  
> The usage is controlled by BOOST_SMART_POINTER_LEGACY_INTERFACE

OK, I see how that could warrant the existence of other macros besides
BOOST_SMART_POINTER_PARAMETERS. Thanks for elaborating.

[...]

> > [...]
> > Probably to have an associative container in MPL, but not 
> > now :). Feel free to contribute, of course.
> 
> Hmm...so if I understand correctly, I would add all the 
> defaults to the container, then add the specified policies 
> according to their categories, overwriting the default values.  
> Then iterate over the container to get the final policies?  

Yep, something like that. For instance,

    namespace aux {
    typedef mpl::map<
          mpl::list<
              scalar_storage<_>
            , assert_check<_>
            , ref_counted<_>
            , disallow_conversion<_>
            >
        , get_category<_> // "key" function
        > smart_ptr_default_params;
    }

    template<
          typename DefaultParamsMap
        , typename Params
        >
    struct params_map_gen
        : mpl::fold<
              Params
            , DefaultParamsMap
            , mpl::insert<_,_>
            >
    {
    };

    template <
        typename T,
        class P1 = empty_policy, class P2 = empty_policy,
        class P3 = empty_policy, class P4 = empty_policy,
        class params_map_ = typename params_map_gen<
              aux::smart_ptr_default_params
            , mpl::list<P1,P2,P3,P4>
            >::type
    >
    class smart_ptr
        : public optimally_inherit<
            optimally_inherit<
                  typename aux::storage_policy<params_map_,T>::type
...

where 'storage_policy' is as simple as this:

    template< typename PolicyMap, typename T >
    struct storage_policy
    {
        typedef typename at<
              PolicyMap
            , storage_policy_tag
            >::type f_;
            
        typedef typename apply_lambda<f_,T>::type type;
    };

> I might be able to hack a cheeseball metamap, though
> not a tree implementation (yet).

At this point I'm more interested in formulating an interface for
associative containers than their implementation qualities, so anything that
works will do.

Aleksey