[parameter] parameters<> and result_of
Objects of the parameters<> type are callable entities, but they do not play well with result_of: BOOST_PARAMETER_KEYWORD(tag, foo) typedef parameter::parameters< parameter::optional< tag::foo > > args_type; // Doesn't compile: typedef result_of< args_type( int const & ) >::type pack_type; args_type args; pack_type pack( args( 1 ) ); Is there any way to tell what the return type of args( 1 ) is? I need to be able to return an argument pack from a generic function. Another feature request: it would be nice if parameters<> were a valid MPL sequence that I could manipulate with MPL algorithms. -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> writes:
Objects of the parameters<> type are callable entities, but they do not play well with result_of:
BOOST_PARAMETER_KEYWORD(tag, foo)
typedef parameter::parameters< parameter::optional< tag::foo > > args_type;
// Doesn't compile: typedef result_of< args_type( int const & ) >::type pack_type;
args_type args; pack_type pack( args( 1 ) );
Is there any way to tell what the return type of args( 1 ) is? I need to be able to return an argument pack from a generic function.
I'll have to get back to you on that one. I don't think there's a nice way, yet.
Another feature request: it would be nice if parameters<> were a valid MPL sequence that I could manipulate with MPL algorithms.
It already is an MPL sequence. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Eric Niebler" <eric@boost-consulting.com> writes:
Objects of the parameters<> type are callable entities, but they do not play well with result_of:
BOOST_PARAMETER_KEYWORD(tag, foo)
typedef parameter::parameters< parameter::optional< tag::foo > > args_type;
// Doesn't compile: typedef result_of< args_type( int const & ) >::type pack_type;
args_type args; pack_type pack( args( 1 ) );
Is there any way to tell what the return type of args( 1 ) is? I need to be able to return an argument pack from a generic function.
I'll have to get back to you on that one. I don't think there's a nice way, yet.
Actually, I think there is. There is a nested template called "argument_pack" that /seems/ to do the right thing, but it's undocumented. And the function-call operators do not use it to declare their return types, so it's anybody's guess whether they're always equivalent. There's also a nested template called "bind", but it's not clear what it is for, or how it differs from "argument_pack".
Another feature request: it would be nice if parameters<> were a valid MPL sequence that I could manipulate with MPL algorithms.
It already is an MPL sequence.
No, it's not. An argument pack is an MPL sequence, but a parameters<> instantiation is not. -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> writes:
I'll have to get back to you on that one. I don't think there's a nice way, yet.
Actually, I think there is. There is a nested template called "argument_pack" that /seems/ to do the right thing, but it's undocumented. And the function-call operators do not use it to declare their return types, so it's anybody's guess whether they're always equivalent.
There's also a nested template called "bind", but it's not clear what it is for, or how it differs from "argument_pack".
We're taking care of it.
Another feature request: it would be nice if parameters<> were a valid MPL sequence that I could manipulate with MPL algorithms.
It already is an MPL sequence.
No, it's not. An argument pack is an MPL sequence, but a parameters<> instantiation is not.
Oh, I see. What would you use that capability for? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Eric Niebler" <eric@boost-consulting.com> writes:
Another feature request: it would be nice if parameters<> were a valid MPL sequence that I could manipulate with MPL algorithms. It already is an MPL sequence.
No, it's not. An argument pack is an MPL sequence, but a parameters<> instantiation is not.
Oh, I see. What would you use that capability for?
I'd use it for the generic object construction utility I sent mail about a few days ago. The constructor parameters for facade<Object> should be the constructor parameters for Object, plus any additional parameters facade<> might need. So I need to be able to manipulate Object's parameters<> at compile time. -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> writes:
David Abrahams wrote:
"Eric Niebler" <eric@boost-consulting.com> writes:
Another feature request: it would be nice if parameters<> were a valid MPL sequence that I could manipulate with MPL algorithms. It already is an MPL sequence.
No, it's not. An argument pack is an MPL sequence, but a parameters<> instantiation is not.
Oh, I see. What would you use that capability for?
I'd use it for the generic object construction utility I sent mail about a few days ago. The constructor parameters for facade<Object> should be the constructor parameters for Object, plus any additional parameters facade<> might need. So I need to be able to manipulate Object's parameters<> at compile time.
So essentially, you need to construct a new parameters<> specialization with additional -- or fewer -- ParameterSpecs? I think it's a fine idea, but I have to say, we're up to our eyeballs in work to do on the parameter library right now. So I guess you should either put it in the tracker for later, or as ever, contribute a most welcome patch. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
David Abrahams -
Eric Niebler