А есть какойто трейдоф между текущими корутинами сo_await и то

что предлагается в пине про libunifex? Я пошёл по ссылке, но там критикуется аллокация, а почему её нельзя избежать я не увидел, но я всё не читал.

Ну и вторая проблема что для корутин нужны практически точно такие же абстракции с практически таким же кодом(просто сравни cppcoro и libunifex) Поэтому и предложение про колбеки, а корутины пусть просто используют этот же код

но зачем писать колбеки, когда во всех других языках делают для удобства await?

А есть статьи на эту тему и когда можно было бы всегда избежать?

в стандарте написано когда можно избежать, а вот как вычислить это - загадка компилятору. Но во всяком случае для стандартных корутин(если они когда то будут), можно захардкодить их поведение

Теоритически можно избежать всегда если известен тип и конечный фрейм, тот кто уже функция а не корутина http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0981r0.html Вот кое что из пропозала выше кст https://github.com/GorNishanov/coroutines-ts/issues/37 Кажется описанный способ работает, но вот компиляторы не слишком любят это оптимизировать как я понимаю

потому что на самом низком уровне корутины не то чтобы есть

учитывая что формально функции - частный случай корутин...

может и частый но редко используемый в своё время

во времена goto наверное очень часто использовали, а потом во время отказа от goto как то и забыли про такую фичу

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

Классический пример когда нельзя избежать - это рекурсия с глубиной неизвестной на компайлтайме (или глубже чем инлайнер отработал). Кажется был пропозал корутин, который просто не поддерживал такой сценарий и мог гарантировать отсутствие аллокаций, но он не прошел. Таким образом в плюсах нельзя гарнтировать отсутствие аллокаций и нельзя расчитывать на это. Оптимизации компилятора это конечно хорошо, но как это должно влиять на концепцию libunifex?

Ну всм влияет на то, что абстракцию делают для чейнинга функторов, а не корутин

То есть претензия в том, что корутины не являются first class citizen? А какие альтернативы? Классический подход в стиле asio на сколько я себе это представляю оперирует корутинами почти точно так же. Разве нет?

а, рекурсия - проблемка. Можно было бы заставить программиста как то самому оборачивать в самрт поинтер. Но видимо в пропозале решили иначе.

Я не понимаю в чём вопрос по-моему в закрепе вполне ясно написано почему авторы делают так, а не чисто корутинный вариант Там абзац текста по сути всего лишь Совсем классический подход с асио это когда ты пишешь по сути конечный автомат на колбеках вручную?

там вообще колбеки в азио, емнип

> Я не понимаю в чём вопрос по-моему в закрепе вполне ясно написано почему авторы делают так, а не чисто корутинный вариант > Там абзац текста по сути всего лишь Возможно я потерял нить рассуждений. > Совсем классический подход с асио это когда ты пишешь по сути конечный автомат на колбеках вручную? Да. В asio все построено на колбэках и корутины умеют встраиваться в такой интерфейс. Я не трогал libunifex, но я не вижу почему оно будет отличаться, так как они по большому счету оперируют теми же коллбэками (чуть более сложными из-за того что их там 3, но принципиальных отличий я не вижу).

Нить обсуждений была, насколько я не понимаю, почему пропозал предлагает sender reciever вместо task, если так можно выразиться И ответ на него: 1) потому что корутины иногда имеют слабо подконтрольный разработчику интерфейс 2) sender могут быть awaitable => нет проблем с тем чтобы реализовать task в их терминах Да оно и не отличается особо, sender/receiver спокойно встраиваются в колбечные интерфейсы скажем так