Boost logo

Boost :

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


Hmm, and it looks like the comma operator is completely missing from 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.

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

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