Boost logo

Boost Users :

Subject: Re: [Boost-users] Odd limitation in Fusion design ?
From: Larry Evans (cppljevans_at_[hidden])
Date: 2010-07-10 09:57:23

On 07/08/10 19:42, John Dlugosz wrote:
>>> So you give it two functions, one to do on the way down and another
>> to do on a the way up?
>> Yes. However, I'm not sure if the way-up function is the NowUp or Else
>> template parameter. I'd have to look at the
>> backus_turingaward_lecture.pdf reference to see which is which.

> My own effort at this, straddling the compile-time and run-time
> boundaries, is posted on a new topic. I can't get the necessarily
> run-time test for done-ness to play nice with the compile-time
> metafunctions that are "run" (expanded) regardless of what might
> happen at run time.
> I'm sure it's a documentation problem with Fusion. There is no
> guarantee that the 'end' iterator evaluates to a unique type that
> won't happen to match the iterator's type inside the normal work.
> For a cons (Lisp-like) list I'm rather certain that it will be,
> unless he's using some kind of type erasure in the implementation,
> but I don't want to make that assumption, and even if that were
> taken, it seems difficult to accomplish (compared with simply
> knowing a simple name for a type that could be used in a partial
> specialization or overloaded form). I'm assuming that there is
> intended to be some simple and natural way to iterate a collection
> other than using the canned fold or for_each functions!


I think I had a similar problem and didn't find a good answer.
The problem was posted in a thread to this list whose last post was:

Anyway, the attached fusion::if_recur does what I was thinking as a
solution. The test driver is also attached with the output. The test
driver uses:

The output shows the reverse of the input going up the recursion stack
and that's why I thought the if_recur might provide the "reverse
processing" that you mentioned in post:

However, the attached fusion::if_recur suffers the problem that the
result_type is fixed by the ElseBtm::result_type. I'm not sure this
can be used to solve the problem of reversing a heterogeneous fusion
sequence since the result_type would have to be the reverse of the
original type.

Anyway, hope this helps.



Compilation finished at Sat Jul 10 08:20:10

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at