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