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-05-29 10:03:56

(reposting because of no response)

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

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

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

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

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?

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

-- Jeremiah Willcock