On 05/18/09 17:19, Steven Watanabe wrote:
AMDG
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 ;-)
Alas. AFAICT, there are no tests or uses for the Backward Predicate in MPL.
However, there may be a use in the future. For example, reverse_find_if. Of course one could implement that by first doing a reverse and then a find_if, but then using that rationale, one could argue there's no need for reverse_fold. I've actually got a use case: error recovery in LL1 parsers. I can't remember the details, but just as find_if could be used to find the first non-nilable element in a spirit sequence, one could use a reverse_find_if to find the last non-nilable element in the same sequence. From the Lewi reference in the vault's Home /Strings Text Processing/LewiLL1.lhs_rhs.zip there's some method of using this to calculate error recovery. IIRC, it's calculated just like the First attribute shown in the vault reference, except the sequence is reversed. There would be no need to reverse the sequence if reverse_find_if were available, and reverse_find_if can be implemented using the BackwardPredicate withe ForwardPredicate being always<true_>.