Boost logo

Boost :

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

shunsuke wrote:
> Joel de Guzman wrote:
>> I think you misunderstood some of my previous posts. value_of is only
>> used to compute the desired result. There is actually no corresponding
>> value_of function. It is only a metafunction, unlike /at/ which has
>> both a result_of metafunction and a function. When the input sequence
>> is actually traversed to generate the result, /at/ is the one being
>> called. Hence, the sequence above is what is actually generated by
>> as_vector.
>> It's unfortunate and a bit unintuitive to be using the result_of scheme
>> to compute the value_at metafunction here. MPL uses the nested "apply"
>> for this purpose. OTOH, it would be annoying to have to use "apply"
>> for value_at and "result" for /at/. It's a compromise.
> 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.


Joel de Guzman

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