Boost logo

Boost :

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

>>>> 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 :
       typename boost::parameter::binding<
     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 --

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

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