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 13:17:34

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

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

>>> 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 currently have a hack to work around this using my parameter_exists
>>> test and some metaprogramming.
>>>
>>> The reason I am working on this low of a level is that I am playing
>>> with converting Boost.Graph named parameter structures into
>>> ArgumentPacks
>>
>> About time!
>
> I know.  I just started playing with it over the weekend.
>
>>> to have access to Boost.Parameter's nicer capabilities
>>> and syntax.  I thus need to build all of the argument data structures
>>> and such within another function and then access them later.
>>
>> I'm not sure what you're saying here, Jeremiah.  Are you talking
>> about building the backward-compatibility interface for the old
>> syntax, here?  The generation macros should be enough to handle all
>> the new-syntax cases.
>
> 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 ;-))

> 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.  In more detail, I'd like to write something like
> (pseudocode):
>
> if parameter color_map is specified {
>   auto color_map = color_map parameter
> } else {
>   std::vector<default_color_type> color_data;
>   auto color_map = f(color_data);
> }
>
> I can stand having something like a dummy int as the default case for color_data, but
> the type of color_map changes based on whether the parameter was specified or not.  Is
> there an easy way to do that?

I don't think this is a Boost.Parameter question, is it?  You already
know how to tell if the parameter was specified, so this looks like a
general TMP issue... right?  Just want to know what question I'm
answering before I try to answer it :-)

> You can also look at the bottom of
> boost/graph/named_function_params.hpp and in
> boost/graph/depth_first_search.hpp (the one file I've tried to
> convert) to see the ways I'm doing things now and what I'm trying to
> do.

Sorry, no time to decode code right now.  Must bug sprint!

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com