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