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-05-26 15:50:39

on Sat May 23 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?

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

> Is there another interface to use?

I'm not sure what you're doing, so I can't say.

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

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

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

> Thank you for your help.

Sure thing; cheers!

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