Boost logo

Boost :

Subject: Re: [boost] [parameter] Testing for existence of a parameter, building ArgumentPacks, more lazy return types
From: David Abrahams (dave_at_[hidden])
Date: 2009-06-03 14:55:43

on Wed Jun 03 2009, Jeremiah Willcock <> wrote:

> On Wed, 3 Jun 2009, David Abrahams wrote:
>> on Tue May 26 2009, Jeremiah Willcock <> wrote:
>>>>> I have a few questions about the parameter library. Please note that I am using
>>>>> argument packs directly, since I am creating them from another data structure.
>>>>> 1. Is there a way to build Boost.Parameter ArgumentPacks from a
>>>>> program?
>>>> Yes, and it's documented. Have you read through the documentation, or
>>>> do you mean something else?
>>> Are you talking about section 3.2.1? I also need to get the types of
>>> the resulting ArgumentPacks.
>> Oh!
>> Hmm, and it looks like the comma operator is completely missing from the
>> reference docs.
> I looked at that ticket, and it doesn't mention the return type thing.

No it doesn't. I just created it because I noticed the comma operator
isn't mentioned in the reference docs.

>>>>> I am currently using many internal data structures of Boost.Parameter
>>>>> (empty_arg_list and such).
>>>> That doesn't sound like a public interface to me, but maybe it should
>>>> be.
>>> Yes, that is the issue. I could use the operators in 3.2.1 but need a
>>> way to get the type of the result.
>> Makes sense. Please open a Trac ticket for that feature.
> OK --
>>>>> 2. Is there a way to tell at compile-time whether a particular
>>>>> parameter exists in an ArgumentPack? I currently have a metafunction
>>>>> that uses a special default type and tests for that; is there a more
>>>>> "official" way?
>>>> Nope, that's the way we recommend.
>>> OK. I guess I would prefer an explicit metafunction for that.
>> Patches welcome :-)
> Does something like this work (tested only in another context):
> struct bgl_parameter_not_found_type {};
> template <typename ArgPack, typename KeywordType>
> struct parameter_exists :
> boost::mpl::not_<
> boost::is_same<
> typename boost::parameter::binding<
> ArgPack,
> KeywordType,
> bgl_parameter_not_found_type
> >::type,
> bgl_parameter_not_found_type> >
> {};

Looks like it. Tests and docs, please. No good deed goes unpunished

>> All I can say is, open the necessary tickets. We always intended that
>> Boost.Parameter be usable for Boost.Graph (although we never imagined
>> you'd take this route to get there ;-))
> Sure, but you understand that interface compatibility is important.


> It would be better to have a single implementation that works with
> both Boost.Parameter and with the old interface (externally), while
> being able to use Boost.Parameter syntax internally.


>>> One more question -- I have a situation where I'd like to declare an
>>> extra variable only when a certain parameter is not specified, and the
>>> type of that variable may not even be valid when the parameter is
>>> specified.
> I solved this another way, so never mind on that.
> A couple more questions:
> 1. Is there a way to create a function that uses Boost.Parameter
> syntax to declare named parameters

You mean the macro syntax that declares functions accepting named

> and then passes an ArgumentPack on to some other function rather than
> decoding that ArgumentPack itself?

Closest we have is the old syntax. See libs/parameter/test/macros.cpp

> That way the same back-end could be used for both functions with
> actual (vararg) named parameters and the old-style interface. Note
> that there are some non-const reference parameters used in BGL.

I'm sorry, I'm missing the significance of what you're trying to do and
of non-const reference parameters.

> 2. Does Boost.Parameter prevent unrecognized keywords from being
> passed to functions? Can a direct user of ArgumentPacks use this
> capability?

I think that currently the answer is no, but I'm not certain.

Dave Abrahams
BoostPro Computing

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