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
>> 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.
>> 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.
-- Shunsuke Sogame
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk