[parameter] Testing for existence of a parameter, building ArgumentPacks, more lazy return types
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? I am currently using many internal data structures of Boost.Parameter (empty_arg_list and such). Is there another interface to use? 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? 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. 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 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. Thank you for your help. -- Jeremiah Willcock
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
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
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
On Wed, 3 Jun 2009, David Abrahams wrote:
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 looked at that ticket, and it doesn't mention the return type thing.
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.
OK -- https://svn.boost.org/trac/boost/ticket/3129
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 :-)
Does something like this work (tested only in another context): struct bgl_parameter_not_found_type {}; template <typename ArgPack, typename KeywordType> struct parameter_exists : boost::mpl::not_< boost::is_same< typename boost::parameter::binding< ArgPack, KeywordType, bgl_parameter_not_found_type >::type, bgl_parameter_not_found_type> > {};
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 already did -- https://svn.boost.org/trac/boost/ticket/3114
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 ;-))
Sure, but you understand that interface compatibility is important. It would be better to have a single implementation that works with both Boost.Parameter and with the old interface (externally), while being able to use Boost.Parameter syntax internally.
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.
I solved this another way, so never mind on that. A couple more questions: 1. Is there a way to create a function that uses Boost.Parameter syntax to declare named parameters and then passes an ArgumentPack on to some other function rather than decoding that ArgumentPack itself? That way the same back-end could be used for both functions with actual (vararg) named parameters and the old-style interface. Note that there are some non-const reference parameters used in BGL. 2. Does Boost.Parameter prevent unrecognized keywords from being passed to functions? Can a direct user of ArgumentPacks use this capability? -- Jeremiah Willcock
on Wed Jun 03 2009, Jeremiah Willcock <jewillco-AT-osl.iu.edu> wrote:
On Wed, 3 Jun 2009, David Abrahams wrote:
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 looked at that ticket, and it doesn't mention the return type thing.
No it doesn't. I just created it because I noticed the comma operator isn't mentioned in 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.
OK -- https://svn.boost.org/trac/boost/ticket/3129
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 :-)
Does something like this work (tested only in another context):
struct bgl_parameter_not_found_type {};
template <typename ArgPack, typename KeywordType> struct parameter_exists : boost::mpl::not_< boost::is_same< typename boost::parameter::binding< ArgPack, KeywordType, bgl_parameter_not_found_type >::type, bgl_parameter_not_found_type> > {};
Looks like it. Tests and docs, please. No good deed goes unpunished ;-)
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 ;-))
Sure, but you understand that interface compatibility is important.
yes.
It would be better to have a single implementation that works with both Boost.Parameter and with the old interface (externally), while being able to use Boost.Parameter syntax internally.
Yes.
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.
I solved this another way, so never mind on that.
A couple more questions:
1. Is there a way to create a function that uses Boost.Parameter syntax to declare named parameters
You mean the macro syntax that declares functions accepting named parameters?
and then passes an ArgumentPack on to some other function rather than decoding that ArgumentPack itself?
Closest we have is the old syntax. See libs/parameter/test/macros.cpp
That way the same back-end could be used for both functions with actual (vararg) named parameters and the old-style interface. Note that there are some non-const reference parameters used in BGL.
I'm sorry, I'm missing the significance of what you're trying to do and of non-const reference parameters.
2. Does Boost.Parameter prevent unrecognized keywords from being passed to functions? Can a direct user of ArgumentPacks use this capability?
I think that currently the answer is no, but I'm not certain. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (2)
-
David Abrahams -
Jeremiah Willcock