FinalAwaitable на 35-м слайде тоже _должен_ реализовать симметричную передачу управления приостановленной (или отсутствующей) корутине. Просто возвращайте всегда из метода FinalAwaitable::await_suspend значение promise.continuation Также непонятно зачем определять собственный оператор co_await для Task. Кстати, если в терминологии promise, то почему Task, а не future? Да ещё и с большой буквы. Разве C# для нас уже стал абсолютным источником замещения наших собственных творческих замыслов и правил С++? :-) Проще и понятнее сделать сам Task (или future) awaitable без переопределения оператора co_await. Тем более, что это действительно просто. Лучше, наверное, привести пример с использованием некоего пула потоков для реализации асинхронного выполения задачи, вместо того, чтобы говорить "я так сделал, но вы так никогда не делайте". Тем более, что для Windows это _вообще_ не проблема - для Linux не знаю, не использую
Для *FinalAwaitable* теоретически можно было бы сделать симметричную передачу управления, но незачем, потому что *FinalAwaitable* используется только на завершении выполнения корутины, т.е. текущую корутину нет смысла возобновлять при симметричной передаче управления, потому что она по сути уже завершилась. Всегда возвращать *promise.continuation* нельзя, потому что продолжение не всегда является валидной корутиной (поэтому есть проверка перед возобновлением). Можно было бы возвращать *promise.continuation* _или_ *std::noop_coroutine()* при симметричной передаче управления, но это получаются приседания ради приседаний, профит такого подхода не понятен. Определение *operator co_await* - _самый простой_ способ (из по крайней мере трёх) сделать возможность ожидать объект какго-либо типа (т.е. звать *co_await* на таком объекте).
Спасибо автору, постарался объяснить все четко. Но по факту, просто пришили сороконожке 41-ю ногу. А зачем? А чтобы было...
Давайте делайте уроки по С++!!!
Это к Константину Владимирову на канал.
Что за корутин и зачем он нужен не возможно понять из этих слов
FinalAwaitable на 35-м слайде тоже _должен_ реализовать симметричную передачу управления приостановленной (или отсутствующей) корутине. Просто возвращайте всегда из метода FinalAwaitable::await_suspend значение promise.continuation
Также непонятно зачем определять собственный оператор co_await для Task. Кстати, если в терминологии promise, то почему Task, а не future? Да ещё и с большой буквы. Разве C# для нас уже стал абсолютным источником замещения наших собственных творческих замыслов и правил С++? :-) Проще и понятнее сделать сам Task (или future) awaitable без переопределения оператора co_await. Тем более, что это действительно просто.
Лучше, наверное, привести пример с использованием некоего пула потоков для реализации асинхронного выполения задачи, вместо того, чтобы говорить "я так сделал, но вы так никогда не делайте". Тем более, что для Windows это _вообще_ не проблема - для Linux не знаю, не использую
Для *FinalAwaitable* теоретически можно было бы сделать симметричную передачу управления, но незачем, потому что *FinalAwaitable* используется только на завершении выполнения корутины, т.е. текущую корутину нет смысла возобновлять при симметричной передаче управления, потому что она по сути уже завершилась. Всегда возвращать *promise.continuation* нельзя, потому что продолжение не всегда является валидной корутиной (поэтому есть проверка перед возобновлением). Можно было бы возвращать *promise.continuation* _или_ *std::noop_coroutine()* при симметричной передаче управления, но это получаются приседания ради приседаний, профит такого подхода не понятен.
Определение *operator co_await* - _самый простой_ способ (из по крайней мере трёх) сделать возможность ожидать объект какго-либо типа (т.е. звать *co_await* на таком объекте).