Ленивая оценка в C++ 14/17 - просто лямбды, а также фьючерсы и т. Д.?

Question

Я только что прочитал:

Lazy Evaluation in C++

и заметил, что это своего рода старый, и большинство ответов рассматривают предварительные 2011 C++. В эти дни у нас есть синтаксические лямбды, которые могут даже вывести тип возвращаемого значения, так ленива оценка, кажется, сводится к просто передавая их вокруг: Вместо

auto x = foo(); 

выполнение

auto unevaluted_x = []() { return foo(); }; 

, а затем оценить, когда/где вам нужно:

auto x = unevaluted_x(); 

Похоже, в этом нет ничего более. Однако один из answers there предлагает использовать futures с асинхронным запуском. Может кто-то изложить, почему/если фьючерсы значимы для ленивой оценки, на C++ или более абстрактно? Кажется, что фьючерсы вполне могут быть оценены с нетерпением, но просто, скажем, в другом потоке и, возможно, с меньшим приоритетом, чем все, что их создало; и в любом случае, это должно быть зависимым от реализации, не так ли?

Кроме того, существуют ли другие современные C++-конструкции, которые полезно учитывать в контексте ленивой оценки?

Answer 1

Когда вы пишете

auto unevaluted_x = []() { return foo(); }; 
... 
auto x = unevaluted_x(); 

Каждый раз, когда вы хотите, чтобы получить значение (при вызове unevaluated_x) он вычисляется, тратить вычислительные ресурсы. Таким образом, чтобы избавиться от этой чрезмерной работы, неплохо было бы отслеживать, была ли уже названа лямбда (может быть, в другом потоке или в другом месте в кодовой базе). Для этого нам нужна обертка вокруг лямбда:

template<typename Callable, typename Return> 
class memoized_nullary { 
public: 
    memoized_nullary(Callable f) : function(f) {} 
    Return operator()() { 
     if (calculated) { 
      return result; 
     } 
     calculated = true; 
     return result = function(); 
    } 
private: 
    bool calculated = false; 
    Return result; 
    Callable function; 
}; 

Пожалуйста, обратите внимание, что этот код является только примером и не поточно.

Но вместо того, чтобы изобретать колесо, вы могли бы просто использовать std::shared_future:

auto x = std::async(std::launch::deferred, []() { return foo(); }).share(); 

Это требует меньше кода писать и поддерживает некоторые другие функции (например, проверить, является ли уже вычислено значение, безопасность потоков, и т.д).

Там в следующий текст в стандарте [futures.async, (3,2)]:

Если launch::deferred установлен в политике, магазины DECAY_COPY(std::forward<F>(f)) и DECAY_COPY(std::forward<Args>(args))... в общем состоянии. Эти копии f и args составляют отложенную функцию. Вызов функции отсрочки оценивает INVOKE(std::move(g), std::move(xyz)), где g - сохраненное значение DECAY_COPY(std::forward<F>(f)) и xyz - сохраненная копия DECAY_COPY(std::forward<Args>(args))..... Любое возвращаемое значение сохраняется в результате совместного использования в результате . Любое исключение, распространяемое от выполнения отложенной функции , сохраняется как исключительный результат в общем состоянии. Общее состояние не создано , пока функция не завершится.Первый вызов функции времени ожидания (30.6.4) в асинхронном объекте возврата, ссылающемся на это состояние общего доступа, должен вызывать отложенную функцию в потоке, который вызвал функцию ожидания. Как только начинается оценка INVOKE(std::move(g),std::move(xyz)), функция больше не считается отложенной. [Примечание. Если эта политика равна , указанной вместе с другими политиками, например при использовании значения политики launch::async | launch::deferred, реализации должны отложить вызов или выбрать политику, когда не будет эффективно использоваться. -End note]

Итак, у вас есть гарантия, что расчет не будет вызываться до того, как он понадобится.

Answer 2

Здесь есть несколько вещей.

Оценка означает оценку аргументов перед передачей их в функцию. Normal order Оценка означает передачу аргументов в функцию перед их оценкой.

Оценка нормального порядка имеет то преимущество, что некоторые аргументы никогда не оцениваются и недостаток, который некоторые аргументы получают снова и снова.

Lazy оценка обычно означает normal order + memoization. Отложите оценку в надежде, что вам вообще не нужно оценивать, но если вам нужно, запомните результат, поэтому вам нужно сделать это только один раз. Важная часть - это оценка термина никогда или один раз, memoization - это самый простой механизм для обеспечения этого.

Модель promise/future другая. Идея здесь заключается в том, чтобы начать оценку, возможно, в другом потоке, как только у вас будет достаточно информации. Затем вы оставляете взгляд на результат как можно дольше, чтобы улучшить шансы, что он уже доступен.

---

promise/future модель имеет некоторые интересные взаимодействия с ленивой оценкой. Стратегия идет:

1. Перенести оценки, пока результат не будет, безусловно, будет необходимо
2. Начните оценку идет в другом потоке
3. ли некоторые другие вещи
4. Фоновый поток завершает и сохраняет результат где-то
5. Исходная нить получает результат

Память может быть аккуратно введена в результате производится фоновым потоком.

Несмотря на синергизм между ними, они не являются одной и той же концепцией.