Operator chaining, why grow left branch?

Question

According to this question (that is, OP stated the belief and was not corrected) - chained operators grow to the left:

a << b << c << d;
// ==
operator<<( operator<<( operator<<(a, b), c ), d);

Why is this the case? Would it not be more efficient to do:

operator<<( operator<<(a, b), operator<<(c, d) );

i.e., to balance as much as possible?

Surely the compiler could figure this out for better runtime performance?

Answer 1

When you overload an operator in C++, it retains the same precedence and associativity that operator has when it's not overloaded.

In the case of shift operators (<< and >>) the standard requires that:

The shift operators << and >> group left-to-right.

That means an operation like a<<b<<c must be parsed as (a<<b)<<c.

Overloading the operator changes the code that's invoked for each of those operations, but has no effect on grouping--the grouping will be the same whether a, b and c are of built-in types (e.g., int) for which the compiler-provided operator will be used, or whether they're some class type for which an overloaded operator will be used. The parser that handles the grouping remains identical either way.

Note, however, that order of evaluation is independent of precedence or associativity, so this does not necessarily affect execution speed.

Answer 2

1. Figuring this out for "better runtime performance" is better served by turning turning operations into CISC. (MULADDs for example.)
2. The synchronization cost between two processors would far outweigh the benefits for any reasonable number of operators that were crammed into one line.
3. This would render out-of-order processing impossible effectively making each core operate at the speed of a Pentium Pro.
4. Aside from the std::cout mentioned by Mystical, think of the following integer arithmetic problem: 3 * 5 / 2 * 4 that should result in (15 / 2) * 4, meaning 28, but if split out it would result in 15 / 8, meaning 1. This is true even though the operators have the same significance.

EDIT:

It's easy to think that we could get away with splitting commutative operations across cores, for example 3 * 5 * 2 * 4.

Now lets consider that the only way to communicate between cores is through shared memory. And that the average load time is an order of magnitude slower than the average CPU operation time. That alone means that a tremendous number of mathematical operations would need to be done before even accommodating 1 load would make sense. But even worse:

1. The master core must write the data and operations to be performed to memory. Because these must be separate there could be a page fault on write.
2. After the master core has finished it's work it must load a dirty bit to check if the slave core has finished processing. It could be busy or have been preempted so this could require multiple loads.
3. The result from the slave core must then be loaded.

You can see how bad that would get given the expense of loads. Lets look at optimizations that can be done if everything is kept on one core:

1. If some values are known ahead of time they can be factored into 2s and shifts can be done instead. Even better a shift and add potentially performing more operations than 1 at a time.
2. For 32-bit or smaller numbers the upper and lower bits of a 64-bit processor may be used for addition.
3. Out of order processing may be done at the CPU's discretion, for example floating point operations are slower than integer operations, so in the situation: 1.2 * 3 * 4 * 5 The CPU will do the 3 * 4 * 5 first and do only 1 floating point operation.