----- Original Message -----
From: Joel de Guzman <joel@boost-consulting.com> To: boost-users@lists.boost.org Cc: Sent: Monday, April 2, 2012 11:26 PM Subject: Re: [Boost-users] [fusion] iterating over a sequence with non-const references
On 4/3/2012 2:45 AM, paul Fultz wrote:
push_back is designed to be non-mutating. That is why. This is true of all the views returned from 'algos', by design. What you can do is to make a container from the view through, e.g. as_vector, as_list. It is *not* true that all sequences return const refs to its elements. Containers definitely return references, otherwise get<N>(c)= expr will not be possible.
Also, front and back return non-const reference, but thats not the point. During iteration, they return const reference. Thats why this is not possible:
struct mutable_func { template<class F> struct result;
template<class F, class T, class U> struct result<F(T, U)> { typedef T type; };
template<class T, class U> T operator()(T && x, U y) const { return x+=y; } };
int i = 0; invoke(foo, tuple<int&, int>(i, 1)); //doesn't compile
here is the output:
What is 'foo'? mutable_func foo = {}; I forgot that line.
Anyway, this (below) compiles fine with me with g++ 4.6.1 and MSVC 10:
Yea, sorry about that. It seems it was still calling my own invoke and there was a mistake in that. If you call invoke like this: std::cout << invoke(mutable_func(), forward_as_tuple(i, 1)) << std::endl; There are two errors: invoke.hpp:209:24: error: non-const lvalue reference to type 'int' cannot bind to a temporary of type 'int' return f( BOOST_PP_ENUM(N,M,~) ); ^~~~~~~~~~~~~~~~~~~~~~~~~ Which I assume is because invoke takes the sequence as a const-reference because it is a temporary. But then why does the other example work(its also a temporary)? The second error is: at_impl.hpp:45:28: error: rvalue reference to type 'int' cannot bind to lvalue of type 'int' return std::get<N::value>(seq); ^~~~~~~~~~~~~~~~~~~~~~~ Which I believe is because of the poor implemetation of tuples in gcc 4.6. I am compiling using clang also. But I do get the same errors in gcc as well. Thanks, Paul Fultz II