Boost logo

Boost :

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:

> > The following zip file in the vault's variadic_template directory:
> >
> >
> >


> 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.


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:

     < 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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at