Re: [boost] [parameter] Testing for existence of a parameter, building ArgumentPacks, more lazy return types

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 <jewillco-AT-osl.iu.edu> wrote:

> On Wed, 3 Jun 2009, David Abrahams wrote:
>
>>
>> on Tue May 26 2009, Jeremiah Willcock <jewillco-AT-osl.iu.edu> 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.  https://svn.boost.org/trac/boost/ticket/3128
>
> 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 -- https://svn.boost.org/trac/boost/ticket/3129
>
>>>>> 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.

yes.

> 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.

Yes.

>>> 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
parameters?

> 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
http://www.boostpro.com