Re: [boost] [fusion] value_at of transform_view

From: shunsuke (pstade.mb_at_[hidden])
Date: 2007-11-22 04:46:23

Joel de Guzman wrote:
> shunsuke wrote:
>> Joel de Guzman wrote:
> 
>>> alas, this uncovers a bug in the implementation where value_at
>>> does not follow above.
>> What is a bug?
> 
> See diff of the source in value_at_impl.hpp for the last 2
> revisions.
> 
>> Is there any pitfall if `value_at` is the same as `at` under transform_view?
> 
> After some more thinking, yes.

I still don't know why, but I know you are always right.

>>> You got me thinking though. It could very well be that you are correct!
>>> Perhaps we need the same behavior for both at/deref and value_at/value_of.
>>> My thinking, OTOH, is that both should get the value_at of the underlying
>>> sequence. Hence, transform(vector<int, int&>, f) will trigger
>>> f this way:
>>>
>>>      int --->  f::result<f(int)>
>>>      int& ---> f::result<f(int&)>
>> No, when vector<int, int&> is mutable lvalue,
>> f should be able to access the mutable int.
>> Hence,
>>
>> int -->  f::result<f(int&)>
>> int& --> f::result<f(int&)>
> 
> I think you are missing the point. It is always mutable with deref and at.
> value_at and value_of should allow you to get the *actual* type of
> the underlying sequence. Think of value_at and value_of as having
> copy semantics.

I understood it probably.
If as_vector means "copy", rvalue should be passed to FunctionObject.

In fact, I'm trying to implement "zip".
If interested, see: http://tinyurl.com/22q6cl
as_vector intercepts mutability.
I'm now lost, but I will retry.

I really apologize my mega-noise.

Regards,

-- 
Shunsuke Sogame