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:
> ...
> # define BOOST_NAMED_PARAMS_SETUP(whatever.hpp, 2, 5)
> #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(
> }
> #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?


>> 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 :)


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