From within the body of the BOOST_PARAMETER_FUNCTION generated function it appears that I can use the name "Args" to refer to the type of the argument
I have a few usage questions for the Boost.Parameter library: 1) If I want to have a function called "policy" that's declared using BOOST_PARAMETER_FUNCTION can I access the types of the arguments both from within the functions body and for the functions return type: BOOST_PARAMETER_FUNCTION( (return-type-computed-from-arguments), policy, tag, // 3. namespace of tag types (optional // optional parameters, with defaults (domain_error, *, throw_on_error) ) (deduced (optional (precision, *, boost::mpl::int_<53>()) ) ) ) { // what type are the arguments? } I realise I can do this with an argument pack, but then either my users will have to call the function with an extra set of parenthesis, or I will have to write a bunch of forwarding functions myself - which itself generates a "what the is the return type" problem. pack, and maybe in the return type as well? But this isn't documented, so can I rely on it? 2) All the arguments I want to pass are actually going to end up being used in meta-programs: for symbolic values, I can make each one a unique enum type, and use the type of the argument (even though it's actually passed as a value) to generate my metacode. But I have one optional argument where I require the value to be an arbitrary compile time constant, the only interface I can come up with at present is something like: policy(_digits10 = mpl::int_<10>()); But I'd really like to be able to write: policy(_digits10 = 12); and have the "12" converted to mpl::int_<12> "by magic", but I can't think of any magic that could be applied here... anyone any ideas? Thanks, John.
John Maddock wrote:
From within the body of the BOOST_PARAMETER_FUNCTION generated function it appears that I can use the name "Args" to refer to the type of the argument pack, and maybe in the return type as well? But this isn't documented, so can I rely on it?
Apparently not, some more experimentation suggests that "Args" can't be easily used to compute the return type; if I use: typename compute_result<Args>::type as the return type of the function in BOOST_PARAMETER_FUNCTION, then everything is OK, provided I don't try and actually extract anything from the type Args inside compute_result, but if I define it as: template <class Args> struct compute_result { typedef typename boost::parameter::value_type< Args, tag::domain_error, throw_on_error_type> ::type type; }; Then I get endless compiler errors starting with: c:\data\boost\release\boost\boost\parameter\value_type.hpp(62) : error C2661: 'boost::mpl::assert_not_arg' : no overloaded function takes 2 arguments c:\data\boost\boost\sandbox\math_toolkit\libs\math\ide\scrap.cpp(83) : see reference to class template instantiation 'boost::parameter::value_type<Parameters,Keyword,Default>' being compiled with [ Parameters=boost::mpl::pair<boost::parameter::aux::empty_arg_list,boost::parameter::void_>, Keyword=tag::domain_error, Default=throw_on_error_type ] c:\data\boost\boost\sandbox\math_toolkit\libs\math\ide\scrap.cpp(101) : see reference to class template instantiation 'compute_result<Args>' being compiled with [ Args=boost::mpl::pair<boost::parameter::aux::empty_arg_list,boost::parameter::void_> ] c:\data\boost\boost\sandbox\math_toolkit\libs\math\ide\scrap.cpp(101) : see reference to class template instantiation 'boost_param_result_101policy<Args>' being compiled with [ Args=boost::mpl::pair<boost::parameter::aux::empty_arg_list,boost::parameter::void_> ] c:\data\boost\release\boost\boost\parameter\value_type.hpp(62) : error C2866: 'boost::parameter::value_type<Parameters,Keyword,Default>::mpl_assertion_in_line_67' : a const static data member of a managed type must be initialized at the point of declaration with [ Parameters=boost::mpl::pair<boost::parameter::aux::empty_arg_list,boost::parameter::void_>, Keyword=tag::domain_error, Default=throw_on_error_type ] c:\data\boost\boost\sandbox\math_toolkit\libs\math\ide\scrap.cpp(101) : error C2146: syntax error : missing ';' before identifier 'type' c:\data\boost\boost\sandbox\math_toolkit\libs\math\ide\scrap.cpp(101) : error C3254: 'boost_param_result_101policy<Args>' : class contains explicit override 'type' but does not derive from an interface that contains the function declaration with [ Args=boost::mpl::pair<boost::parameter::aux::empty_arg_list,boost::parameter::void_> ] c:\data\boost\boost\sandbox\math_toolkit\libs\math\ide\scrap.cpp(101) : error C2838: 'type' : illegal qualified name in member declaration c:\data\boost\boost\sandbox\math_toolkit\libs\math\ide\scrap.cpp(101) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int Obviously it's not easy to figure out what's going on here, given that this happens inside a macro expansion :-( Thanks for any insight, John.
John Maddock wrote:
John Maddock wrote:
From within the body of the BOOST_PARAMETER_FUNCTION generated function it appears that I can use the name "Args" to refer to the type of the argument pack, and maybe in the return type as well? But this isn't documented, so can I rely on it?
Yes, you can rely on it. It's supposed to be documented, but this feature seems to have gotten completely lost somewhere along the way. Here's a patch for it: --- preprocessor.hpp 29 Sep 2006 00:31:28 -0000 1.5.2.9 +++ preprocessor.hpp 27 May 2007 16:01:40 -0000 @@ -149,7 +149,8 @@ , typename Parameters::deduced_list , tag_keyword_arg , mpl::false_ - >::type type; + >::type result; + typedef typename mpl::first<result>::type type; }; I'll be checking this in on HEAD and RC shortly. Thank you for reporting it, -- Daniel Wallin Boost Consulting www.boost-consulting.com
Daniel Wallin wrote:
Here's a patch for it:
--- preprocessor.hpp 29 Sep 2006 00:31:28 -0000 1.5.2.9 +++ preprocessor.hpp 27 May 2007 16:01:40 -0000 @@ -149,7 +149,8 @@ , typename Parameters::deduced_list , tag_keyword_arg , mpl::false_ - >::type type; + >::type result; + typedef typename mpl::first<result>::type type; };
I'll be checking this in on HEAD and RC shortly.
I've confirmed that this fixes the issue, but don't see the patch in either HEAD or RC branches. In the mean time I've opened track ticket 1044 on this. Regards, John.
participants (2)
-
Daniel Wallin -
John Maddock