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-08 13:04:54

On 04/08/09 10:35, David Abrahams wrote:
> on Sun Apr 05 2009, Larry Evans <cppljevans-AT-suddenlink.net> wrote:
> 
>> Just as the ForwardPredicate is "augmented" with protection
>> against dereferencing the end<numbers>::type in this code:
>>
>> https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/iter_fold_if.hpp#L42
>>
>> shouldn't the BackwardPredicate also be augmented with the same
>> protection here:
>>
>> https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/iter_fold_if.hpp#L77
> 
> Well, it doesn't need to be; if it did, tests and uses wouldn't compile
> ;-)
> 
> Just think about how you'd implement it and it should become obvious why.
> 
My first guess at how to implement it is just change the result_ to:

     typedef
         aux::iter_fold_if_impl<
           first_
         , State
         , ForwardOp
         , protect< aux::iter_fold_if_pred< ForwardPredicate,last_ > >
         , BackwardOp
         , protect< aux::iter_fold_if_pred< backward_pred_  ,last_ > >
         >
     result_;

However, it's not obvious to me yet why this wouldn't work.  Maybe if
I tried to compile it, it would become obvious.

Before I go to that trouble and if you've the time and inclination,
could you give me some hint about why the if_recur in my recent post
couldn't replace iter_fold_if?  AFAICT, the only purpose of
BackwardPredicate is to prevent selected BackwardOp applications
"on the way out" (to quote from

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

). However, that role could be performed by the BackwardOp itself,
couldn't it?  The counterpart to the BackwardOp in if_recur
is the NowUp binary function.  NowUp has access to all the
information that BackwardPred and BackwardOp have (and it knows
it's not at the end iterator, because that's handled by the
eval_if test.

The advantage of if_recur is that it's more
understandable (at least to me) and doesn't suffer the problem of
a casually coded BackwardPredicate allowing the BackwardOp to
deref an end iterator (that's what happened to me and
what lead to my suggestion about protecting BackwardPredicate).

-regards,
Larry