[proto] folding a proto tree in reverse
I need to traverse a proto tree from right to left so that given the
statement:
(a, b, c) = expr;
I can assign in order c then b and lastly a.
A fragment that does the order a,b,c (and work, but not very
efficiently, which is why I want to go the other way) is:
template<typename E>
struct assign_aux {
assign_aux (const E& rhs) : m_rhs (rhs) {}
typedef int result_type;
template<typename T>
int operator()(const T& t, int offset) const {
int next_offset = offset - actual_width_transform () (t);
int value = systemc_eval (m_rhs.range (offset,next_offset+1));
const_cast
Sorry for the noise, please disregard the previous post. I was missing the state in the invocation of the fold. Which is ok, when you don't have a data (it gets default constructed, which would have been ok for me), but cannot possibly work with data. --
Maurizio Vitale wrote:
Sorry for the noise, please disregard the previous post. I was missing the state in the invocation of the fold. Which is ok, when you don't have a data (it gets default constructed, which would have been ok for me), but cannot possibly work with data.
Good, I was just sitting down to write a response. So did you get it working with proto::reverse_fold_tree?. Using fusion algorithms with proto::flatten will surely lead to long compile times. -- Eric Niebler BoostPro Computing http://www.boostpro.com
"Eric" == Eric Niebler
writes:
Eric> Maurizio Vitale wrote: >> Sorry for the noise, please disregard the previous post. I was >> missing the state in the invocation of the fold. Which is ok, >> when you don't have a data (it gets default constructed, which >> would have been ok for me), but cannot possibly work with data. Eric> Good, I was just sitting down to write a response. So did you Eric> get it working with proto::reverse_fold_tree?. Using fusion Eric> algorithms with proto::flatten will surely lead to long Eric> compile times. proto::reverse_fold_tree worked just fine in the end. I'm not too concerned about compilation time at this point. Rather the assembly code generated when evaluating fixed-point arithmetic shouldn't be too far from what you'd write by hand. Maurizio
participants (3)
-
Eric Niebler
-
Maurizio Vitale
-
Maurizio Vitale