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:
>> 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:
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:
COMPILE.cmd=/usr/bin/g++-4.1 -c -Wall -ftemplate-depth-100 -O0
iter_fold_if_bkprotect.cpp -MMD -o
BD Software STL Message Decryptor v3.10 for gcc 2/3/4
: In instantiation of 'boost::mpl::deref<
iter_fold_if_bkprotect.cpp:37: instantiated from here
error: no type named 'item' in 'boost::mpl::l_end'
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
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk