Re: [Boost-users] Odd limitation in Fusion design ?

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!
[snip]

John,

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:

http://thread.gmane.org/gmane.comp.lib.boost.user/58611/focus=58612

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:

http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/iostreams/utility/indent_scoped_ostreambuf.hpp

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:

http://article.gmane.org/gmane.comp.lib.boost.user/60210

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.

-regards,
Larry



/home/evansl/prog_dev/boost-svn/ro/trunk/sandbox-local/build/gcc4_4v/boost-svn/ro/sandbox/rw/variadic_templates/libs/fusion/sandbox/if_recur.exe 
show_default=9
  increment:state=0
    increment:state=1
      increment:state=2
        increment:state=3
          print_btm:state_btm=4
        print_pair:state_now=3:state_up=4
      print_pair:state_now=2:state_up=4
    print_pair:state_now=1:state_up=4
  print_pair:state_now=0:state_up=4
show_less_increment=4

Compilation finished at Sat Jul 10 08:20:10