Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-11-22 19:46:40

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.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at