Joel de Guzman wrote:
shunsuke wrote:
I might probably understand this problem.
transform_view, in order to implement `deref` etc, uses `result_of` in the standard manner, where `result<F(int)> means that rvalue is passed.
Correction: result<F(int&)> which means lvalue is passed. The lvalue is correctly propagated through the transform.
But, as_vector applied to transform_view uses `result_of` in a strange manner through value_of.
A FunctionObject for transform_view requires two result_of implementations; It seems impossible.
I provided an example, didn't I? Actually, there's another way to do it -- take a look at how fusion zip does it.
Ok, tell you what: I understand the confusion. If you or anyone else can find a way to do value_at that passes the exact underlying element (undecorated) type, through the transform function, then, I'd gladly rethink this matter. Here's a possibility: struct identity { template <class FunCall> struct result; template <class Fun, class T> struct result<Fun(T&)> { typedef T& type; }; template <class T> struct value { typedef T& type; }; template <class T> T& operator()(T& v) const { return v; } }; That would add another requirement to the PolymorphicFunctionObject concept though and is not compatible with prior schemes. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net