Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk