Re: [boost] [mpl]iter_fold_if Forward Backward rationale?

Subject: Re: [boost] [mpl]iter_fold_if Forward Backward rationale?
From: David Abrahams (dave_at_[hidden])
Date: 2009-03-13 19:49:10

On Mar 9, 2009, at 10:00 AM, Larry Evans wrote:

> Why is there both a ForwardOp and BackwardOp template argument to
> iter_fold_if?
>
> https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/iter_fold_if.hpp 
> #L62
>
> I would have thought that only 1 was needed.

Yeah, only one is needed if you are only interested in traversing the  
list forward (or backward).  iter_fold_if is supposed to be the most  
general linear traversal algorithm, upon which all the others can be  
built.  Remember that list structures can only be built backwards, and  
think about the use of inserters and such with the sequence  
constructing algorithms.

> Since iter_fold_if is not documented here:
>
> http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/refmanual_toc.html
>
> I assume it's not meant to be used by the user, but is only an
> implementation detail;

I think that was probably an oversight

> however, it, or a variation, might be useful to
> implement the and_seq mentioned here:
>
>
>  http://article.gmane.org/gmane.comp.lib.boost.devel/186204
>
> As shown in that post, the template, while_if_then was used, and it
> does not require anything like both a ForwardOp and BackwardOp, it
> just requires the If and Then unary metafunctions.  One problem I
> encountered with while_if_then was moving to the end of the sequence,
> at which time the Then metafunction couldn't be called; hence, I had
> to make it lazy to avoid dereferencing the end iterator.  Is that
> somehow related to the need for BackwardOp in iter_fold_if.

No.

> IOW,
> because iter_fold_if might reach the end iterator, it has to backup?
>
> I'm really asking because in the variadic template version of mpl, I
> wondering if iter_fold_if could be replaced with something like
> while_if_then (which may be renamed fold_if to be more consistent with
> other names with similar function).
>
> Any insight about the rationale for the iter_fold_if would probably
> save me considerable time in deciding whether it can be replaced with
> the proposed fold_if.

HTH,

--
David Abrahams
BoostPro Computing
http://boostpro.com