велкам ту сипласплас. Еще скажи спасибо, если компилятор конструкторы копирования лишние повыкидывает.

Expression templates. Eigen и другие библиотеки линейной алгебры так это и делают (включая std::valarray).

Не проще ли обычный builder pattern сделать? И нагляднее и проще.

Слабо себе представляю как можно сделать ленивость поверх стандартных операторов. Ведь кто-то должен запустить выполнение.

Слабо себе представляю как можно сделать ленивость поверх стандартных операторов. Ведь кто-то должен запустить выполнение.

Влоб. Можно сделать класс Expression. Операторы перегрузить так, чтобы они принимали в качестве аргументов как требуемые классы, так и выражения, но возвращали всегда выражение. И определить преобразование из Expression в требуемы классы. Соответственно, выполнение будет запускаться в момент преобразования из типа Expression.

https://stackoverflow.com/questions/414243/lazy-evaluation-in-c

Забыл, что можно возвращать произвольный класс из оператора...

Неслабо так «забыл».

Со стандартными операторами есть дефолтная ленивость.

Например,

if(func1() && func2())

func2 не будет выполнено, если func1 вернёт false

с перегруженными операторами не прокатит, но фичу удобно использовать для воспроизведения ленивости в определённых ситуациях

Разве это не ub?

Нет, но это и не lazy evaluation. Скорее short circuit, пруф - http://c-faq.com/expr/shortcircuit.html

стандартом совершенно точно определено, искать по ключевым словам short-circuit evaluation

Вот и весь ваш lazy evaluation

template  <class T>
class X
{
Func* f = nullptr; //вместо Func либо typedef указателя на функцию
//либо std::function, либо ещё какая обёртка, на свой вкус
T t;
public:
T& get()
{
   return f ? t, f(t);
}
T& set(const T& _t, Func* _f)
{
   t = _t, f = _f;
   return t;
}
operator T&() 
{
  return get();
}

};

short-circuit позволяет условно тоже самое, но только в пределах одного выражения

Что-то такое встречал. Сейчас гугл подсказывает только то, что не для всех операторов задан чёткий порядок. Это не UB, как бы, но порядок выполнения действительно может быть произвольный:

https://stackoverflow.com/a/7925696/1153097

http://en.cppreference.com/w/cpp/language/eval_order

http://en.cppreference.com/w/cpp/language/operator_precedence

«Every overloaded operator obeys the sequencing rules of the built-in operator it overloads when called using operator notation.»

«Operators that have the same precedence are bound to their arguments in the direction of their associativity.»

из этого следует, что в выражении

std::cout<<"s"<<1<<func1()<<func2()<<func(3);

Порядок вычислений функций func1, func2, func3 неопределён, однако, как раз, операторы «<<» выполнятся в порядке слева направо.

Да. Я имел ввиду ситуацию вида:

void func(int i) {}

int i = 1;
std::cout << func(i++) << func(i++);

Ну это уже чисто инкрементов/декрементов проблемы. Лично я считаю, что их следует избегать, кроме простейших выражений. Просто потому, что плохо читаются и при модификации выражения грозят внезапным «ой».

Не совсем. Такое поведение гарантируется стандартом:

void func1(int &i) { assert(i == 1); i++; }
void func2(int &i) { assert(i == 2); i++; }

int i = 1;
std::cout << func1(i) << func2(i);

?

вообще не скомпилируется: применение оператора к ф-ии, возвр. void

но если, она будет возвращать ссылку на &int и написать return i, как вы, очевидно, хотели, то нет, не гарантируется