Boost logo

Boost :

Subject: Re: [boost] [mpl]iter_fold_if Forward Backward rationale?
From: David Abrahams (dave_at_[hidden])
Date: 2009-04-13 17:40:28


on Thu Apr 09 2009, Larry Evans <cppljevans-AT-suddenlink.net> wrote:

> On 04/08/09 10:35, 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#L42
>>>
>>> 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#L77
>>
>> Well, it doesn't need to be; if it did, tests and uses wouldn't compile
>> ;-)
>>
>> Just think about how you'd implement it and it should become obvious why.
>>
> David,
>
> 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. 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; whether
you'll evaluate the predicate on a past-the-end position is a non-issue.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk