LVV>>А в каких задачах корутины вот прям супер — супер? LVV>>Чего раньше приходилось делать муторно и долго ? Pzz>В задачах задавания каверзных вопросов на зачете и собеседовании. ну, я про корутины читал еще в глубоком СССР чуть ли не в в 70-е годы.
Но как-то не видел в текущих задачах применения.
А вот нафига их включили в стандарт ?
Лучше бы сетевую библиотеку включили.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Иногда удобно, чтоб поток продолжился с того места где закончился. Это реванш goto-поклонников. Но иногда действиетльно удобно без всякой возни с потоками и мьютексами
Например на Unity ни одна игра практически без Корутин не обходится. Да, там шарп, а не плюсы, но суть та же.
Просто корутины в плюсы хоть и добавили, но пока там кучу обязательных манипуляций сделаешь — понимаешь, что проще поток новый завести и не мудрить
Здравствуйте, LaptevVV, Вы писали:
Pzz>>В задачах задавания каверзных вопросов на зачете и собеседовании. LVV> ну, я про корутины читал еще в глубоком СССР чуть ли не в в 70-е годы. LVV>Но как-то не видел в текущих задачах применения.
Те, про которые ты читал в Союзе, это легковесные нитки.
А эти — способ сделать код на callback-ах напоминающим на вид многопоточный код. Потому, что многопоточный параллелизм проще понять, чем код, организованный в виде машины состояний, реагирующей на события.
Pzz>>>В задачах задавания каверзных вопросов на зачете и собеседовании. LVV>> ну, я про корутины читал еще в глубоком СССР чуть ли не в в 70-е годы. LVV>>Но как-то не видел в текущих задачах применения. Pzz>Те, про которые ты читал в Союзе, это легковесные нитки.
Не. Ссыль на первичную статью Конвея.
И характерные картинки с зигзагами.
Pzz>А эти — способ сделать код на callback-ах напоминающим на вид многопоточный код. Потому, что многопоточный параллелизм проще понять, чем код, организованный в виде машины состояний, реагирующей на события.
Ок. Поразмышляю.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>А в каких задачах корутины вот прям супер — супер? LVV>Чего раньше приходилось делать муторно и долго ?
Ну это концептуально то же самое, что и yield return в C#. Полезно может быть в тех же сценариях, где традиционно используется паттерн Iterator, только без реализации разнообразных классов итераторов. Например, для каких-то кастомных обходов деревьев.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, LaptevVV, Вы писали:
LVV>Чего раньше приходилось делать муторно и долго ?
Оно позволяет писать линейно и "синхронно" код с асинхронным выполнением подзадач.
Sic luceat lux!
Re: В написании линейного кода, который прерывается сетью/диском
Здравствуйте, LaptevVV, Вы писали:
LVV>А в каких задачах корутины вот прям супер — супер? LVV>Чего раньше приходилось делать муторно и долго ?
В написании кода вида:
Coroutine function(int argument) {
auto r1 = get_data_from_disk("filename.txt");
auto r2 = http_request("https://google.com/hahaha");
auto sum = r1 + r2;
co_return sum;
}
С корутинами таких можно запустить параллельно 100 штук и поток на всё это нужен только один, который, пока ничего не происходит (диск двигает голову, пакеты идут в гугл) может поделать что-то ещё другое.
Без корутин запускать 100 таких задач в один поток — это жесть и содомия с коллбэками вида "поменяй указатель на функцию и вернись" и куча этих функций.
Здравствуйте, pkl, Вы писали:
pkl>С корутинами таких можно запустить параллельно 100 штук и поток на всё это нужен только один, который, пока ничего не происходит (диск двигает голову, пакеты идут в гугл) может поделать что-то ещё другое. pkl>Без корутин запускать 100 таких задач в один поток — это жесть и содомия с коллбэками вида "поменяй указатель на функцию и вернись" и куча этих функций.
А в чём принципиальное отличие от async/await?
Re[3]: В написании линейного кода, который прерывается сетью
Здравствуйте, Dair, Вы писали:
D>А в чём принципиальное отличие от async/await?
async ориентирован на работу с разными потоками, а корутины ориентированы на работу в одном потоке. При работе с async вызывающая и вызываемая функции могут выполняться асинхронно и одновременно. У корутин же в каждый момент времени активна только какая-то одна, а другая находится в "подвешенном" состоянии (suspended). Корутины можно рассматривать как новый способ ветвления программы. Ну или как на многократно вызываемую функцию, которая между вызовами "помнит" своё состояние и продолжает выполняться с того места, с которого она вернула управление при прошлом вызове.
Лично мое имхо: в С++20 использование корутин слишком громоздко и код не упрощает от слова "совсем". Как по мне, то проще наколбасить сколько нужно кастомных итераторов. По крайней мере, это будет более привычно. А вот начиная с 23-го стандарта появляется полезная штуковина: std::generator, после чего, я ожидаю, что корутины станут более юзабельными.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, Dair, Вы писали:
D>>А в чём принципиальное отличие от async/await?
R>async ориентирован на работу с разными потоками, а корутины ориентированы на работу в одном потоке.
Здравствуйте, Dair, Вы писали:
D>А в чём принципиальное отличие от async/await?
Я читал что оно есть, но похоже так толком и не понял в чем (не смогу "объяснить шестилетнему ребенку").
Насколько я понял, async/await — это частный случай короутин, который легко понять и использовать.
В случае async/await "вложенность" ожидания идет по вызовам. В этом случае код получается практически линейным, легким для понимая (и в то же время не-блокирующий, т.е. асинхронный)
В случае же ко-роутин вложенность может быть любая, или ее вообще может не быть. То есть, насколько я, опять же, понимаю,
это вообще может быть линейный код, без вызовов функций, с исполнением просто прыгающим из одного места в другое.
Или две функции могут исполняться "параллельно" с исполнением перепрыгивающим из одной в другую.
Генераторы — это калька того что есть в других языках, это не о том.
Найти статью показывающую "на пальцах" преимущество ко-роутин перед "банальным" async/await у меня не получилось.
Было бы интересно если бы кто пояснил в чем их крутость на простом примере (желательно без кода)
Здравствуйте, Евгений Музыченко, Вы писали:
LVV>>А в каких задачах корутины
ЕМ>Вы вроде не мальчик, должны были застать слово "сопрограмма", а туда же...
Знаете чем отличается авторство от соавторства
Тем же чем пение от сопения
Мне больше по душе постепенно исполняемы функции, чем сопрограммы(корутины). Они явно требую кванта исполнения, в отличии от "сопрограм" которые вызываются (где попало) в разных тредах, колбяках, без каких либо ограничений.
А в С++ пошли еще дальше вотвам лего можете собрать что угодно, при чем скорей всего разные поделки будут совершенно не совместимы друг с другом.
Более того обычный C позволяет их писать еще со своего появления и без C++20.
И основная засада тут не в генераторах, асинках, авейтах или фьючах. Основная подстава в гарантиях которые необходимо соблюдать, но при этом их даже не декларируют.
Здравствуйте, kov_serg, Вы писали:
_>Мне больше по душе постепенно исполняемы функции
Это уже объяснение однословного термина, которое в словаре идет после дефиса/двоеточия.
Corutine/сопрограмма — вполне удачный термин для подпрограммы, код которой выполняется по шагам попеременно с кодом вызывающей программы. Придумали их где-то в 60-е, если не раньше, и на русский переводили именно как "сопрограмму". Но поддерживались они только в редких специфических языках, поэтому писали их в основном на ассемблерах (на которых тогда традиционно писались конечные автоматы обработки событий), поэтому широкого распространения термин не получил.
А когда появились реализации в универсальных языках, то "эффективные переводчики", для любого незнакомого термина на автомате вставлявшие кальку, даже не подумали заглянуть в старые словари, вот и прижилось очередное уродливое слово.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А когда появились реализации в универсальных языках, то "эффективные переводчики", для любого незнакомого термина на автомате вставлявшие кальку, даже не подумали заглянуть в старые словари, вот и прижилось очередное уродливое слово.
Я как раз про реализацию. Вместо явной передачи управление её стараются скрыть под капотом, более того внетреннее состояние тоже прячут. Зато потом ноуют вот бы нам "сопрограммы" которые могли сохранять своё состояние.
Здравствуйте, kov_serg, Вы писали:
_>Вместо явной передачи управление её стараются скрыть под капотом, более того внетреннее состояние тоже прячут.
Это все от того, что развитием C++ в основном уже давно занимаются люди, понимающие программирование, как "запись алгоритма средствами языка", а не как обеспечение выполнения нужных действий с нужной степенью понятности, эффективности, применимости и т.п.
