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: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2009-06-03 14:04:25

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.

>>>> 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> >
{};

>>>> 3. I have a case where the default type for a named parameter cannot
>>>> be instantiated in some cases where that parameter is given
>>>> explicitly.  The operator||() lazy defaults don't seem to work for
>>>> that because they get the result_type member from my default right
>>>> away, even if it won't be used.
>>>
>>> Ouch.  It would be nice to have a fix for that one.
>
> Can you open a ticket?

I already did -- https://svn.boost.org/trac/boost/ticket/3114

>> Yes -- I am starting with keeping the old external interfaces (only)
>> and translating the implementation to use Boost.Parameter internally.
>> This means that users will not see any changes and yet the internals
>> of BGL can use Boost.Parameter default computation and such.  Later,
>> once that's working, the external interfaces can be switched.
>
> 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 and then passes an ArgumentPack on to some other 
function rather than decoding that ArgumentPack itself?  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.

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

-- Jeremiah Willcock