From: shunsuke (pstade.mb_at_[hidden])
Date: 2007-11-22 02:45:58
Joel de Guzman wrote:
> shunsuke wrote:
>> I tend to think `value_at` of transform_view should be the same as
>> `result_of::deref` of transform_view.
>> I'm not sure, though.
> value_at (as well as value_of) returns (essentially):
> while at (as well as deref) returns (essentially):
> alas, this uncovers a bug in the implementation where value_at
> does not follow above.
What is a bug?
Is there any pitfall if `value_at` is the same as `at` under transform_view?
> 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&)>
The current deref works like this unless as_vector is used.
typedef int& type;
int& operator()(int& i) const
// This compiles fine.
typedef boost::fusion::vector<int, int> from_t;
from_t from(10, 20);
boost::fusion::transform_view<from_t, ::identity> v(from, ::identity());
*boost::fusion::begin(v) = 999;
BOOST_CHECK(boost::fusion::at_c<0>(from) == 999);
//boost::fusion::as_vector(v); // error!
Here, as_vector calls value_of. Hence,
int --> f::result<f(int)>
My poor identity doesn't compile.
IMHO, as_vector should be able to return vector<int&, int&>.
Once as_vector intervenes, FunctionObject can't access mutable elements in a tuple.
For example, mutable STL iterator can't be returned from std::string in a tuple.
-- Shunsuke Sogame
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk