Comments 11
Интересно, какие накладные расходы несет использование корутин? Есть какие-нибудь тесты про это?
Вот да. Когда люди выбирают писать на плюсах, они берут на себя множество сложностей: и полуручное управление памятью, и странную типизацию, и много другого непонятного. Но делают они это ради основного бонуса плюсов - низкими, понятными и управляемыми накладными расходами и реалтаймом. Но как в это укладываются современные тенденции вроде жиреющей стандартной библиотеки, и всех этих лямбд/корутин/многопоточности я не понимаю.
Хорошо, я не профессиональный программист, я могу этого не понимать. Но мне кажется, что и профессиональные программисты, которых я встречаю по жизни (без учёта эмбеддеров, те любят современные плюсы за constexpr и шаблоны) вообще не задумываются как их код будет вести себя в реале. Их не интересует вопрос накладных расходов совсем. К примеру, они думают, что раз смартпоинтеры на плюсах, раз они в стандартной библиотеке, значит они zero-cost abstraction, или "оверхед мааааленький", и любой pointer должен быть smart. Зачем тогда писать на плюсах, для этого есть Java.
Извините какой то бред.
они берут на себя множество сложностей: и полуручное управление памятью, и странную типизацию, и много другого непонятного
Управления памятью вручную нет, странная типизация - первый раз слышу такое обвинение С++, "много другого" - непонятно о чём это.
Но как в это укладываются современные тенденции вроде жиреющей стандартной библиотеки, и всех этих лямбд/корутин/многопоточности я не понимаю
Претензии по поводу библиотеки непонятны, не подключил - не используешь, максимум что получишь чуть больше файлик конечный, разве что эмбедеры почувствуют( и всё равно всё решаемо)
Лямбды, корутины - внутри очень понятные и простые штуки, ничем не сложнее обычной структурки или функций. Оптимизируют компиляторы это очень хорошо.
Чем вам многопоточность не угодила я вообще не понимаю
И последнее, насчёт смартпоинтеров - накладные расходы действительно минимальны, если используется к месту. Естественно если всё в проекте заменить на shared_ptr, то это испортит проект, но С++ исходит из предположения, что программист не идиот
Какие-то несёт. Как минимум на аллокации invocation record (того, что у корутин вместо стека) и переключения туда-сюда. Многое зависит от того, насколько хорошо написана библиотека поддержки корутин.
Но корутины не будут заменять обычный линейный код, это бессмысленно. Они будут заменять или FSM, или код с мешком коллбэков, или futures. Тут есть неплохая вероятность получить ускорение за счёт более внятного кода. Если сравнивать folly::Future и корутины оттуда же, то мы получили небольшое ускорение за счёт того, что future всегда запускается асинхронно, а корутина может выполниться синхронно если проскочить мимо всех co_await.
А теперь с этим всем на борту мы попытаемся взлететь
А что случилось с std::promise, почему его нельзя использовать?
Сейчас применение корутин несколько напоминает сборку пазла, картинки-загадки, в условиях, когда тот, кто пазл собирает, не видел картинки, которая у него должна получиться
А представьте каково будет тому, кому придётся разбираться и поддерживать код который был написан таким образом.
Все эти проблемы у автора потому что он пытается писать библиотеку поддержки корутин самостоятельно. Разумеется это сложно, попробуйте в том же питоне написать asyncio самостоятельно или даже понять что там написано. Если же взять готовую библиотеку, то становится гораздо легче и писать, и разбираться.
Корутины в C++20 — что это и как с ними работать