Leniwe oceny w C++ 14/17 - tylko lambdy, a także futures itp.?

Question

Właśnie przeczytałem:

Lazy Evaluation in C++

i zauważył, że to trochę stary i większość odpowiedzi uważają pre-2011 C++. W dzisiejszych czasach mamy składniowe lambdy, które można nawet wywnioskować typ zwracany, ocena tak leniwy wydaje się sprowadzać po prostu przekazując je wokół: Zamiast

auto x = foo(); 

wykonać

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

a następnie ocenić, kiedy/gdzie musisz:

auto x = unevaluted_x(); 

Wydaje się, że nie ma w tym nic więcej. Jednak jeden z modeli answers there sugeruje użycie asynchronicznego uruchamiania przy użyciu futures. Czy ktoś może wyjaśnić, dlaczego/jeśli przyszłość jest ważna dla leniwych prac ewaluacyjnych, w C++ lub bardziej abstrakcyjnie? Wydaje się, że futures można bardzo dobrze ocenić z niecierpliwością, ale po prostu, powiedzmy, w innym wątku i być może z mniejszym priorytetem niż to, co je stworzyło; i tak czy inaczej, powinna być zależna od wdrożenia, prawda?

Czy są też inne współczesne konstrukcje C++, o których warto pamiętać w kontekście leniwej oceny?

Answer 1

Kiedy piszesz

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

każdym razem, gdy chcą uzyskać wartość (podczas rozmowy unevaluated_x) to obliczone, marnowania zasobów obliczeniowych. Tak więc, aby pozbyć się tej nadmiernej pracy, dobrze jest śledzić, czy lambda została już wywołana (może w innym wątku lub w innym miejscu w bazie kodu). Aby to zrobić, potrzebujemy opakowania o wartości 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; 
}; 

Należy pamiętać, że ten kod jest tylko przykładem i nie jest bezpieczny dla wątków.

Ale zamiast wymyślania koła, można po prostu użyć std::shared_future:

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

wymaga mniej kodu do zapisu i obsługuje kilka innych funkcji (jak sprawdzić, czy wartość została już obliczone, bezpieczeństwo nici, itp).

Jest dodaje się tekst w standardowym [futures.async, (3,2)]:

Jeśli launch::deferred jest w polityce, sklepy DECAY_COPY(std::forward<F>(f)) i DECAY_COPY(std::forward<Args>(args))... we wspólnym państwie. Te kopie f i args stanowią odroczoną funkcję. Inwokacja funkcji odroczonej ocenia INVOKE(std::move(g), std::move(xyz)), gdzie g jest zapisaną wartością DECAY_COPY(std::forward<F>(f)) i xyz jest przechowywaną kopią DECAY_COPY(std::forward<Args>(args)).... Każda wartość zwracana jest przechowywana jako wynik w stanie współdzielonym. Każdy wyjątek propagowany po wykonaniu opóźnionej funkcji jest przechowywany jako wyjątkowy wynik w stanie współdzielonym. Stan wspólny nie jest gotowy do ukończenia funkcji .Pierwsze wywołanie funkcji czasu bez oczekiwania (30.6.4) na asynchronicznym obiekcie zwracającym, odnoszącym się do tego stanu współużytkowanego, powinno wywołać funkcję odroczoną w wątku, który wywołał funkcję oczekiwania. Po rozpoczęciu oceny INVOKE(std::move(g),std::move(xyz)) funkcja nie jest już uważana za odroczoną. [Uwaga: Jeśli ta zasada ma wartość określona razem z innymi zasadami, na przykład podczas korzystania z wartości strategii launch::async | launch::deferred, implementacje powinny odroczyć wywołanie lub wybrać zasadę, jeśli nie można efektywniej wykorzystać współbieżności. -lub wstępna]

Masz więc gwarancję, że obliczenia nie zostaną wywołane, zanim będzie to konieczne.

Answer 2

Jest tu kilka rzeczy.

Applicative order ewaluacja oznacza ocenę argumentów przed przekazaniem ich do funkcji. Normal order ewaluacja oznacza przekazanie argumentów do funkcji przed ich oceną.

Ocena normalnego zamówienia ma tę zaletę, że niektóre argumenty nigdy nie są oceniane, a wada, że ​​niektóre argumenty są oceniane wielokrotnie.

Lazy ocena zwykle oznacza normal order + memoization. Odłóż ocenę w nadziei, że wcale nie musisz oceniać, ale jeśli musisz, zapamiętaj wynik, więc musisz zrobić to tylko raz. Ważną częścią jest ocenianie terminu nigdy lub raz, najprostszym mechanizmem tego jest zapamiętywanie.

Model promise/future znów jest inny. Chodzi o to, aby rozpocząć ocenę, prawdopodobnie w innym wątku, gdy tylko dostępna jest wystarczająca ilość informacji. Następnie odkładasz wynik tak długo, jak to możliwe, aby zwiększyć szanse, że jest już dostępna.

---

Model ma interesującą synergię z leniwą oceną. Strategia idzie:

1. Postpone ocenę aż pewnością będą potrzebne wynikiem
2. Zacznij ocenę dzieje w innym wątku
3. Czy jakieś inne rzeczy
4. Gwint tło uzupełnia i zapisuje wynik gdzieś
5. Początkowy wątek powoduje odczytanie wyniku:

Zapamiętywanie może być starannie wprowadzone, gdy wynik jest tworzony przez wątek tła.

Pomimo synergii między tymi dwoma, nie są one tym samym pojęciem.