[fusion] discrepancy between std::accumulate and fusion::accumulate

Hello, I just started playing with an abstracted accumulate function which can be called either with a fusion sequence or a range, and calls fusion::accumulate or std::accumulate as appropriate. In using it, I ran into an interesting discrepancy: std::accumulate expects binary functions which take the accumulator as the first argument and the sequence element as the second argument. fusion::accumulate expects the arguments in reverse. This discrepancy makes the abstraction unnecessarily complicated, because the binary function has to either be able to receive the arguments in either order, or be adapted (e.g., with bind) for one of the cases. Or, I'm just missing something :-) I guess I just wanted to point this out - perhaps it might be a useful thing to mention in the docs. BTW, MPL follows the standard library convention. Kind regards, Stjepan

on Fri Sep 19 2008, "Stjepan Rajko" <stipe-AT-asu.edu> wrote:
Hello,
I just started playing with an abstracted accumulate function which can be called either with a fusion sequence or a range, and calls fusion::accumulate or std::accumulate as appropriate. In using it, I ran into an interesting discrepancy: std::accumulate expects binary functions which take the accumulator as the first argument and the sequence element as the second argument. fusion::accumulate expects the arguments in reverse. This discrepancy makes the abstraction unnecessarily complicated, because the binary function has to either be able to receive the arguments in either order, or be adapted (e.g., with bind) for one of the cases. Or, I'm just missing something :-)
I consider this a Fusion bug. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

Stjepan Rajko wrote:
Hello,
I just started playing with an abstracted accumulate function which can be called either with a fusion sequence or a range, and calls fusion::accumulate or std::accumulate as appropriate. In using it, I ran into an interesting discrepancy: std::accumulate expects binary functions which take the accumulator as the first argument and the sequence element as the second argument. fusion::accumulate expects the arguments in reverse. This discrepancy makes the abstraction unnecessarily complicated, because the binary function has to either be able to receive the arguments in either order, or be adapted (e.g., with bind) for one of the cases. Or, I'm just missing something :-)
I guess I just wanted to point this out - perhaps it might be a useful thing to mention in the docs. BTW, MPL follows the standard library convention.
Indeed. A bug. Fusion should follow std convention. Can you please add a trac ticket? Sigh... this will be a breaking change. I wonder why it went unnoticed :-( Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

On Fri, Sep 19, 2008 at 7:30 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
Indeed. A bug. Fusion should follow std convention. Can you please add a trac ticket? Sigh... this will be a breaking change. I wonder why it went unnoticed :-(
Added: http://svn.boost.org/trac/boost/ticket/2355 Thanks, Stjepan
participants (3)
-
David Abrahams
-
Joel de Guzman
-
Stjepan Rajko