Faule Bewertung in C++ 14/17 - nur Lambdas oder auch Futures etc.?

Question

Ich habe gerade gelesen:

Lazy Evaluation in C++

und bemerkte, es ist eine Art alt ist und die meisten Antworten betrachten Pre-2011 C++. In diesen Tagen wir syntaktische lambdas haben, die sogar den Rückgabetyp ableiten kann, so faul Auswertung scheint nach unten zu kochen, um sie nur um vorbei: Statt

auto x = foo(); 

Sie

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

ausführen und dann bewerten, wenn/wo Sie brauchen:

auto x = unevaluted_x(); 

Scheint so, als gäbe es nichts mehr. Einer der answers there schlägt jedoch vor, futures mit asynchronem Start zu verwenden. Kann jemand erläutern, warum/wenn Futures für Lazy-Evaluation-Arbeit, in C++ oder abstrakter sind? Es scheint, als ob Futures sehr wohl eifrig bewertet werden könnten, aber einfach, sagen wir, in einem anderen Thread und vielleicht mit weniger Priorität als alles, was sie geschaffen hat; und sowieso sollte es umsetzungsabhängig sein, oder?

Gibt es auch andere moderne C++ - Konstrukte, die im Zusammenhang mit einer faulen Auswertung sinnvoll sind?

Answer 1

Wenn Sie

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

Jedesmal, wenn Sie den Wert erhalten möchten, schreiben (wenn Sie unevaluated_x nennen) berechnet ist, verschwenden Rechenressourcen. Also, um diese übermäßige Arbeit loszuwerden, ist es eine gute Idee zu verfolgen, ob das Lambda bereits aufgerufen wurde (vielleicht in einem anderen Thread oder an einer anderen Stelle in der Codebasis). Um dies zu tun, müssen wir einige Wrapper um Lambda:

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; 
}; 

Bitte beachten Sie, dass dieser Code ist nur ein Beispiel und ist nicht Thread-sicher.

Aber statt das Rad neu zu erfinden, könnte man einfach std::shared_future verwenden:

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

Dieser weniger Code erfordert einige andere Funktionen zu schreiben und unterstützt (wie prüfen, ob hat sich der Wert bereits berechnet worden ist, Thread-Sicherheit, etc).

Es gibt den folgenden Text in dem Standard [futures.async, (3.2)]:

Wenn launch::deferred in Politik, speichert DECAY_COPY(std::forward<F>(f)) und DECAY_COPY(std::forward<Args>(args))... im freigegebenen Zustand gesetzt. Diese Kopien von f und args bilden eine verzögerte Funktion. Der Aufruf der verzögerten Funktion wertet INVOKE(std::move(g), std::move(xyz)) aus, wobei g der gespeicherte Wert DECAY_COPY(std::forward<F>(f)) ist und xyz die gespeicherte Kopie von DECAY_COPY(std::forward<Args>(args)).... ist. Jeder Rückgabewert wird als Ergebnis im gemeinsamen Status gespeichert. Jede Ausnahme, die von der Ausführung der zurückgestellten -Funktion propagiert wird, wird als Ausnahmeergebnis im gemeinsam genutzten Zustand gespeichert. Der gemeinsame Status wird nicht bereit gemacht, bis die Funktion abgeschlossen ist.Der erste Aufruf einer nicht zeitgesteuerten Wartefunktion (30.6.4) an einem asynchronen Rückgabeobjekt, das sich auf diesen gemeinsamen Zustand bezieht, muss die zurückgestellte Funktion im Thread aufrufen, der die Wartefunktion aufgerufen hat. Sobald die Auswertung von INVOKE(std::move(g),std::move(xyz)) beginnt, wird die Funktion nicht länger als verzögert angesehen. [Hinweis: Wenn diese Richtlinie zusammen mit anderen Richtlinien angegeben wird, z. B. bei Verwendung eines Richtlinienwerts launch::async | launch::deferred, sollten Implementierungen den Aufruf oder die Auswahl der Richtlinie verzögern, wenn kein Concurrency mehr effektiv ausgenutzt werden kann. -end note]

Sie haben also eine Garantie, dass die Berechnung nicht aufgerufen wird, bevor sie benötigt wird.

Answer 2

Es gibt ein paar Dinge hier los.

Applicative order Auswertung bedeutet, Argumente zu bewerten, bevor sie in eine Funktion übergeben werden. Normal order Auswertung bedeutet, dass die Argumente in eine Funktion übergeben werden, bevor sie ausgewertet werden.

Normale Reihenfolge Auswertung hat den Vorteil, dass einige Argumente nie ausgewertet werden und der Nachteil, dass einige Argumente immer wieder ausgewertet werden.

Lazy Bewertung bedeutet in der Regel normal order + memoization. Verschieben Sie die Auswertung in der Hoffnung, dass Sie überhaupt keine Auswertung vornehmen müssen, aber wenn Sie es müssen, denken Sie an das Ergebnis, so dass Sie es nur einmal tun müssen. Der wichtige Teil ist die Bewertung eines Begriffs nie oder nur selten, Memoisierung ist der einfachste Mechanismus, um dies zu erreichen. Das Modell promise/future ist wieder anders. Die Idee hier ist, eine Bewertung zu starten, wahrscheinlich in einem anderen Thread, sobald Sie genügend Informationen zur Verfügung haben. Sie lassen dann das Ergebnis so lange wie möglich zurück, um die Chancen zu verbessern, dass es bereits verfügbar ist.

---

Das promise/future Modell hat einige interessante Synergie mit lazy evaluation. Die Strategie geht:

1. Auswertung aufschieben, bis das Ergebnis auf jeden Fall benötigt werden
2. die Auswertung starten
in einem anderen Thread geht
3. einige andere Sachen tun
4. Der Hintergrund-Thread beendet und speichert das Ergebnis irgendwo
5. Der erste Thread ruft das Ergebnis ab

Memoization kann ordentlich als Ergebnis eingefügt werden wird vom Hintergrundthread erzeugt.

Trotz der Synergie zwischen den beiden sind sie nicht das gleiche Konzept.