<Update> As usual for me, the question was a wrong one. The actual question is: why doesn't transform_iterator use the conventional result_of<> metafunction to determine the return type, instead of accessing UnaryFunc::result_type directly. Posted an answer with a work around. </Update>
Specifically, is there a way to make a phoenix expression expose a result_type
type as expected for the std::unary_function concept? boost::transform_iterator seems to expect this, and from looking at the src of it, I don't see a simple work around.
Here's some code that reproduces the problem I've been having:
#include <boost/iterator/transform_iterator.hpp>
#include <boost/spirit/home/phoenix.hpp>
#include <numeric>
#include <iostream>
using namespace boost::phoenix;
using namespace boost::phoenix::arg_names;
int main(void){
int i[] = {4,2,5,3};
std::cout <<
std::accumulate(
boost::make_transform_iterator(i, _1*_1),
boost::make_transform_iterator(i+4, _1*_1),
0
) << std::endl;
return 0;
}
The relavent portion of the error message from compiling this is (gcc 4.3.4, boost 1.43):
/usr/include/boost/iterator/transform_iterator.hpp:43: error: no type named ‘result_type’ in ‘struct boost::phoenix::actor<...
I have the same problem with boost::lambda (missing result_type
). I thought that I had seen similar usage for make_transform_iterator and lambda in the past, now I'm wondering if I just imagined it.
Is there a provided wrapper or some other mechanism in phoenix or lambda to expose result_type
?