On 05/29/09 16:02, Steven Watanabe wrote: ]snip]
The only case where it is significantly more convenient to use the backward predicate is when doing both a forward and a reverse operation. For this case, what is really needed is the ability to give iter_fold_if a lambda expression which will be used to package the result of the forward operation for the backwards operation. (This is all premature generalization of course...)
IIUC, this "lambda expression..for the backwards operation" would be used to test if the BackwardPred were satisifed, and only then would the oringinal backwards operation be applied; otherwise, the backward operation would just be the identity operation. If so, then that's what I was suggesting here: 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? from: http://article.gmane.org/gmane.comp.lib.boost.devel/188358 Now AFAICT, the if_recur template, mentioned in the previous sentence to that suggestion, is functionally equivalent to the your proposed modification to iter_fold_if_impl because it doesn't have the BackwardPred either. The difference is that if_recur doesn't have the 2 calls to BOOST_PP_REPEAT whose only purpose, AFAICT, is to alleviate the "template instantiation depth" limitation described here: http://www.mywikinet.com/mpl/paper/mpl_paper.html#sequences.unrolling The advantage of if_recur is that it's clearer because: 1) if_recur doesn't try to alleviate the template instantiation depth problem and therefore doesn't use any BOOST_PP_REPEAT calls. Such BOOST_PP_REPEAT calls obscure the code. Maybe there's some if_unrolled_recur, based somehow on if_recur, that could alleviate the template instantiation depth problem using BOOST_PP_REPEAT. However even if if_unrolled_recur is used, the if_recur code should be kept around for documentation. IOW, just as the mpl_paper.html document showed fold_impl before and after the unrolling, the rationale or implementation doc for if_unrolled_recur would show the original (and clearer) if_recur and explain how if_unrolled_recur was derived from if_recur based on the pattern in the mpl_paper (or some other document within mpl docs or boost docs). 2) The other reason if_recur is clearer is that it generalizes the fold problem into a recursive if-else problem. The recursive if-else is clearer because everyone is familiar with both the if-else construct and recursion and the if_recur just has fewer template parameters than iter_fold_if_impl and this makes it easier to understand. Of course those if_recur template parameters have to be constructed from the ForwardPred and ForwardOp and BacwardOp args to iter_fold_if, but that has to be done with the existing code. In this case, the generalization is a help w.r.t. code clarity; hence, I don't think it should be characterized as premature generalization. Actually, the only reason for the while_ template mentioned here: http://article.gmane.org/gmane.comp.lib.boost.devel/188775 is to allow the short-circuiting going up the recursion stack, an advantage not possible with if_recur. I thought that would be more acceptable than if_recur because it seemed important in this post: http://article.gmane.org/gmane.comp.lib.boost.devel/171634 If short-circuiting is considered an advantage, then why not use the while_? [snip]