Re: [boost] [mpl]iter_fold_if Forward Backward rationale?

Subject: Re: [boost] [mpl]iter_fold_if Forward Backward rationale?
From: Larry Evans (cppljevans_at_[hidden])
Date: 2009-04-22 12:19:00

On 04/21/09 11:36, Larry Evans wrote:
 > On 04/15/09 11:39, Larry Evans wrote:
[snip]

 >  > The following zip file in the vault's variadic_template directory:
 >  >
 >  >   http://preview.tinyurl.com/c6h7vc
 >  >

[snip]

 > replaced.  This enabled seeing where the errors were occuring. Also,
 > several MPL_ASSERTS were placed in that file to check where the end
 > iterator was being passed to the iter_fold_if_backward_step
 > template. The *.sizeI.compile files shows where the assertions fail.
 > There's always at least one assertion failure.  The number of failures
 > is governed by the size of the input sequence.
 >
 > AFAICT, the iter_fold_if_backward_step should never be passed the end
 > iterator; hence, there's a bug in iter_fold_if_impl.hpp.

[snip]

There's now in the same vault directory, while.cpp.  This demonstrates
how a while_ template can be used with an explicit stack to avoid the
problems of iter_fold_if accessing the end iterator.  The exlicit
stack is the 3ird parameter to:

   template
     < typename Iter
     , typename State
     , typename Stack
     >
   struct forward_state
   ;

This stack is built up during the 1st while_ instantiation and then
that stack is traversed during the 2nd while_ instantiation.  IOW, an
explicit stack is used to simiulate recursion.  I think that's about
what iter_fold_if_impl was doing with the forward_stepI, for I=0,4 as
well as a recursive call to itself.  However, as noted above, it
mistakenly assumed forward_stepI::iterator, for i=0,3, was not the end
iterator.

A nice side effect of this solution is the while_ could be used to
solve the {or,and)_problem reported here:

   http://article.gmane.org/gmane.comp.lib.boost.devel/185908

-regards,
Larry