On 04/13/09 16:40, David Abrahams wrote:
on Thu Apr 09 2009, Larry Evans <cppljevans-AT-suddenlink.net wrote:
[snip]
With the change shown in attachment, the mpl tests passsed, as shown in the vault's:
Of course it does. The change has no effect, because the predicate is never executed on the past-the-end position.
The following zip file in the vault's variadic_template directory: http://preview.tinyurl.com/c6h7vc contains: 1) iter_fold_if_bkprotect.cpp 2) iter_fold_if_bkprotect.compile 3) iter_fold_if.hpp The .cpp file compiles with the change; however, without the change, it fails to compile with some error message suggesting an attempt to deref l_end: -{--compilation-- COMPILE.cmd=/usr/bin/g++-4.1 -c -Wall -ftemplate-depth-100 -O0 -fno-inline -I/home/evansl/prog_dev/boost-svn/ro/boost-trunk iter_fold_if_bkprotect.cpp -MMD -o /home/evansl/prog_dev/boost-svn/ro/boost-trunk/sandbox/build/gcc4_1/boost-vrtmp/libs/mpl/sandbox/iter_fold_if_bkprotect.o BD Software STL Message Decryptor v3.10 for gcc 2/3/4 /home/evansl/prog_dev/boost-svn/ro/boost-trunk/boost/mpl/list/aux_/iterator.hpp : In instantiation of 'boost::mpl::deref< boost::mpl::l_iter<boost::mpl::l_end> >': ... iter_fold_if_bkprotect.cpp:37: instantiated from here /home/evansl/prog_dev/boost-svn/ro/boost-trunk/boost/mpl/list/aux_/iterator.hpp:39: error: no type named 'item' in 'boost::mpl::l_end' -}--compilation-- The .compile file shows the complete error message. The .hpp file is the existing iter_fold_if.hpp modified with an '#ifdef PROTECT_BACK_PRED' which selects whether or not to use the suggested change. Now, if the predicate is never executed on the past-the-end position, then what causes the above error message? I assumed that, because of the above error message and because BackwardPred in the attachment was always<true_>, that it was tested on the past-the-end position (i.e. l_end) and returned true, which then allowed the BackwardOp to execute, which then casued the above error message. That assumption is supported by the lack of an error message when there's '#define PROTECT_BACK_PRED'. I can't think of another explanation. What am I missing? What's strange to me is that when the input sequence is a range_c, the .cpp compiles without the change, but when the input sequence is a list_c, the .cpp compile requires the change. There's an '#ifdef USE_LIST_C' which selects which input sequence is used.
When recursing inward, you need to terminate recursion when you reach the end *or* when the forward predicate is satisfied, and you can't test the forward predicate on the past-the-end position. When recursing outward, the backward predicate simply tells you whether to keep applying the operation or not;
That's about what I thought. I'm guessing that the BackwardPred allows "short-circuiting", i.e. as soon as the first false_ is encountered, the recursion stops. If so, then there's a definite advantage of iter_fold_if over the if_recur attached to post: http://article.gmane.org/gmane.comp.lib.boost.devel/188322 Does the BackwardPred allow such short-circuiting, somewhat like what happens when evaluating mpl::and_ or mpl::or_, but only starting from the back? I appreciate your patience. -regards, Larry