shunsuke wrote:
Joel de Guzman wrote:
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.
No. By the standard, `result<F(int)>` means that rvalue is passed, and `result<F(T&)>` means that lvalue is passed.
Exactly! And, again, `deref` uses `result<F(T&)>` --as expected.
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?
That doesn't work with rvalues.
Of course it does :-) Did you try it? The example I attached (in the trac ticket) can even work with mpl::vector.
With regard to standard manner, result<> implementation of `f` is wrong. So, that does't work with transform_view.
Actually, there's another way to do it -- take a look at how fusion zip does it.
I will apply that way(Preprocessor programming) if no workaround is found.
Again, see fusion zip. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net