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-15 12:39:32

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