Re: [boost] Re: [Review] Named parameters library

From: Doug Gregor (dgregor_at_[hidden])
Date: 2004-11-24 11:56:35

On Nov 23, 2004, at 2:26 PM, David Abrahams wrote:
>> 1) We need a params.has(k) member, that returns mpl::true_ when the
>>    parameter is there and mpl::false_ when the parameter is not
>>    there. That lets us dispatch either statically or dynamically based
>>    on the existence of an argument for keyword k.
>
> Seems like that interface makes static dispatch unneccessarily hard.
> How about a metafunction:
>
>     has_param<Params, k>
>
> such that
>
>     has_param<Params, k>
>
> is derived from either mpl::true_ or mpl::false_ and
>
>     has_param<Params, k>::type
>
> is one of mpl::true_ or mpl::false_.

Yes, that's better.

>> 2) The macro BOOST_NAMED_PARAMS_FUN is okay when all parameters may be
>>    named parameters. In my use cases, there are always several
>>    positional-only parameters for which I do *not* want the option to
>>    rename them, and may want to be more picky about how they are
>>    passed to the function. For instance, I want to be able to take a
>>    "Graph& g" as the first parameter. One way to address this would be
>>    another variant of this macro, which I'll lamely call
>>    BOOST_NAMED_PARAMS_FUN_EXT, that might work like this:
>>
>> 	BOOST_NAMED_PARAMS_FUN_EXT(void, page_rank, 0, 3, 
>> detail::page_rank_keywords,
>>                              (2, (typename Graph, typename RankMap)),
>>                              (2, ((Graph&, g), (RankMap rank))))
>>
>> The first new argument is a preprocessor array giving the extra
>> template parameters that should be introduced into the function. The
>> second new argument is also a preprocessor array, this one containing
>> the parameter types and names (each as tuples). I believe there is
>> enough information here to generate, e.g.,
>>
>>    template<typename Graph, typename RankMap>
>>    void page_rank(Graph& g, RankMap rank)
>>    { return page_rank_with_named_params(g, rank,
>>    detail::page_rank_keywords()()); }
>>
>>    template<typename Graph, typename RankMap, typename T0>
>>    void page_rank(Graph& g, RankMap rank, const T0& a0)
>>    { return page_rank_with_named_params(g, rank,
>>    detail::page_rank_keywords()(a0)); }
>>
>>    etc...
>
> Probably something like that could work.  But my intuition tells me
> this is a good candidate for vertical repetition:
>
>   #ifndef BOOST_PP_IS_ITERATING
>
>   ...
>
>   # define BOOST_NAMED_PARAMS_SETUP(whatever.hpp, 2, 5)
>   # include BOOST_NAMED_PARAMS_GENERATE
>   #else
>
>   template <class Graph, class RankMap BOOST_NAMED_PARAMS_TYPES>
>   void page_rank(Graph& g, RankMap rank BOOST_NAMED_PARAMS_ARGS)
>   {
>     return page_rank_with_named_params(
>         g, rank, BOOST_NAMED_PARAMS_KEYWORDS);
>   }
>
>   #endif
>
> Otherwise it's just too ugly and unreadable, not to mention what
> happens when types contain commas.

I'm thinking both are a bit too ugly... the Graph library might just be 
weird in this regard (having a single non-named parameter at the 
beginning of every function).  Maybe I'll think of something else.

>> 3) Partly due to the missing "params.has(p)", we're lacking the
>>    ability to determine the type of an expression like
>>    "params[index_map | get(vertex_index, g)]" without passing it to
>>    another function. I'd gladly give up some clarity in the handling
>>    of default parameters if I could get at this information. I'd even
>>    go for an auto-like macro:
>>
>> 	BOOST_NAMED_PARAMS_AUTO(index, index_map, get(vertex_index, g));
>
> Yikes; that one is hard without some kind of typeof support.
>
>
> How about:
>
>  	BOOST_NAMED_PARAMS_AUTO(index, index_map, some-type-expression);
>
> ??

Well, we'd need to have that get(vertex_index, g) in there somewhere 
for the auto to expand properly. Just having something like

        typename param_type<Params, index_map_t, default-type>::type

would suffice for most uses.

> You already have some way to look up the type of
>
>   get(vertex_index, g)
>
> right?

Yes.

>> 2) Keywords are stated to be of type "boost::keyword<keyword
>>    type>". Can we derive from the appropriate boost::keyword<...>
>>    instead? This is important to the BGL for backward compatibility
>>    reasons.
>
> I honestly don't know.  If we can, we should enable it.

Well, it seems to work on Apple GCC 3.3 :)

        Doug