为什么STL数值算法使用'op'而不是'op ='？

Question

Why do std::numeric algorithms seem to prefer op instead of op= ? For example, here is the implementation of std::accumulate in LLVM:

template <class _InputIterator, class _Tp>
inline _LIBCPP_INLINE_VISIBILITY
_Tp
accumulate(_InputIterator __first, _InputIterator __last, _Tp __init)
{
    for (; __first != __last; ++__first)
        __init = __init + *__first;
    return __init;
}

Would this not be potentially more efficient/less verbose/better if implemented using the += operator?

Answer 1

It is defined like this in the standard…

The standard is defined in terms of + , not += :

26.7.2 Accumulate [accumulate]

 template <class InputIterator, class T> T accumulate(InputIterator first, InputIterator last, T init); template <class InputIterator, class T, class BinaryOperation> T accumulate(InputIterator first, InputIterator last, T init, BinaryOperation binary_op); 

Effects: Computes its result by initializing the accumulator acc with the initial value init and then modifies it with acc = acc + *i or a cc = binary_op(acc, *i) for every iterator i in the range [first,last) in order.

Same holds for other numerical algorithms.

…and the standard is based on STL…

But that's the reason why they're implemented like this nowadays. However, to learn about the original reason, one needs to go further down the rabbit hole :

Requirements on types

For the first version, the one that takes two arguments:

• InputIterator is a model of Input Iterator.
• T is a model of Assignable.
• If x is an object of type T and y is an object of InputIterator 's value type, then x + y is defined.
• The return type of x + y is convertible to T .

…and the STL has been created by…?

So, why is that? Lets ask Alexander Stepanov, the mind behind STL:

[A] user has asked a [question] on StackOverflow two days ago concerning the implementation and formulation of numerical algorithms like accumulate or inner_product , which are defined in terms of + instead of += (section 26.7 in ISO C++11).

I've tried to find some rationale behind the decision, but even the version on SGI's page doesn't mention anything regarding this particular choice of the operator.

Was the choice of the operator (a = a + b instead of a += b) only based on your personal preference, as some comments assume? Was a+b the more natural way to write the operation back then? Or was it simply a matter of symmetry between a = a +b and a = bin_op(a,b)?

-- [Zeta]

Now, before you read his answer, remember that he started to write a generic library about ~30 years ago, and his and Meng Lee's initial document The Standard Template Library will have its twenty years anniversary this October. Without further ado, I present his answer:

I suspect that it was a matter of symmetry between a = a + b and a = bin_op(a,b), but I really do not remember. I should have written a rationale document stating all the reasoning between different design choices in STL, but I did not. Sorry.

^{(If Stepanov reads this by any chance: thanks again for your answer!)}

I personally believe that the inspiration by Common Lisp's reduce has been another factor, but that's just speculation.

What can one learn from this?

Sometimes, decision in a standard are based on personal preference and elegance. For example, if Stroustrup had written the STL, he would have "strongly prefer[ed] the use of a+=b as being a more direct expression of intent and typically faster than a=a+b". However, I have to admit that the symmetry between a = a+b and a=bin_op(a,b) has its own beauty.

That being said, this a+=b and a=a+b controversy will promote challenges:

This issue will become very important when we define standard concepts, and I do not know how it will be resolved. [Stroustrup; also thanks to him for answering my question!]

That's all, I hope you've enjoyed the ride through a little bit of C++ history.

Answer 2

It might be more efficient, and would clearly be less verbose.

The usual reason for doing things this way is to minimize the requirements on the underlying type. If you used += , then the underlying type would have to support += . For something like int that's trivial and already present, but for a class you define, it's entirely possible would define + and = , but not the compound += (in which case, code that used += would obviously fail).

Answer 3

在我看来，主要原因是你可以使用标准功能对象std::plus并获得与operator +相同的结果，就像在std::sort等排序算法中使用operator <和标准功能对象std::less一样。

Answer 4

There are plenty of reasons for using + instead of +=.

A. Because it is the correct way. Accumulate is fold , a functor (a function that maps functions to functions) that operates on +, not +=. Why + instead of +=? Because += is not a mathematical function.

B. It is more efficient (on modern compilers, on all primitive types and well-designed objects). += might be faster for compilers 30 years ago, but + is faster now, unless what you are accumulating is a monstrous object with too much OO. Object lifetime analysis is easier done on const objects rather than references.

C. It is clearer. This reason is really not substantially different from (A). + is clearer than +=. Clarity trumps verbosity.

Answer 5

The truth, I guess, is reuse. The rest of the STL is using binary operators while += is an action . So there's plus , multiplies , etc, but no add_action (say). Operators and actions are completely symmetric, but if you implement more than 90 algorithms, at some point you'll probably have to stop adding new concepts and Ship It.

Alex has said that he never intended for his STL to be the end of all STL development, esp. since the standardized version contains only a fraction of what he originally proposed. This is an obvious extension.