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#L4...
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#L7...
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