optimizing binary arithmetic operations using move semantics

Question

I'm experimenting with the rvalue references with a simple Vector class, trying to eliminate unneeded temporaries in binary operations. After a little bit of struggle, I found that with the following two overloads for operator+():

// overload called if right = lvalue and left = lvalue/rvalue
friend Vector<T> operator+(Vector<T> a, const Vector<T>& b) {
  a += b;
  return a;
}

// overload called if right = rvalue and left = lvalue/rvalue
friend Vector<T> operator+(const Vector<T>& a, Vector<T>&& b) {
  b += a;
  return std::move(b);
}

I can ensure that in an expression like auto x = a+b+c+d+...;, as long as at least a or b is a temporary, the move constructor will be called without creating any new temporaries.

On the other hand even if one of the values after a and b (say d) is lvalue, that should technically be enough to avoid the copy. Is there any optimization that can compiler can do by scanning a given expression to find at least one temporary and start calling the operator+ based on that value?

Example 1:

#include "vector.h"

Vector<double> get() {
  return {0, 1, 2, 6};
}
int main (){
  auto a = get();
  auto b = get();
  auto c = a + get() + b;
  std::cout << c << std::endl;

  return 0;
}

Output:

calling move ctor
calling move ctor
[0, 3, 6, 18]

Example 2:

#include "vector.h"

Vector<double> get() {
  return {0, 1, 2, 6};
}
int main (){
  auto a = get();
  auto b = get();
  auto c = a + b + get();
  std::cout << c << std::endl;

  return 0;
}

Output:

calling copy ctor
calling move ctor
[0, 3, 6, 18]

Answer 1

I guess the answer is negative. In your code

auto c = a + b + get();

The compiler must first call operator+() on a and b. This execution order is predefined in laguage specification I think. The compiler should not execute b + get() first, because different execution order can result in different return value for (a + b + get()), along with different side effects. So the order of execution should remain unchaged.

And is there something compiler can do with a + b part in the first place? As both a and b are l-value, compiler must choose a function which takes two l-value argumenets. It's not that compiler developers cannot add new optimizations, but that compiler should only do as specified in language. Suppose that compiler uses r-value version of your function for a + b. And then, in your function, a or b will be modified (as they are r-value), which is something not intended: why do we need to modify operands to get the sum of them?

And if you are willing to make a and b modifiable in your function, just can cast them as r-value before calling your function, like std::move(a) + std::move(b) + get()

Hope this helps.