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