по аналогии с подпиской на сигнал, только вместо коннекта надо вешать эвент фильтр из пробуждать корутину из него
детали мне неведомы я еще ни одной корутины на с++ не писал пока только читаю портянки кода других людей.
выкладывайте, будет интересно посмотреть

Очень годная лекция которая в целом отвечает на вопрос "а чо так сложна" https://www.youtube.com/watch?v=R_gZQJC-uv0

Нет, это он приводит пример корутины которая не начинает сразу "рваться в бой" а стопается сразу при входе в неё (https://youtu.be/R_gZQJC-uv0?t=2047)

Поэтому чтобы начать ее исполнение надо позвать resume() в первый раз. В примере который мы рассматривали выше (с сигналами) initial_suspend не тормозил корутину.
Зачем такое нужно? Например "ленивые" вычисления - вы отдельно создали корутину, а исполнили ее код когда-нибудь потом, когда она реально понадобится.

Да, лектор поясняет этот момент через неск секунд после того как я "иссяк" Сегодня досмотрел до конца, во второй раз пошло значительно легче.

Выходит "корутины" - это по сути возможность выполнить не всю ф-цию, а ее часть/кусок. Само по себе это никак не связано с асинхронностью, фоновым выполнением и.т.п. Еще раз тот же кусок кода

C++ (Qt)
while (true) {
   qDebug() << "entering loop";
   co_await qtcoro::make_awaitable_signal(changeTimer, &QTimer::timeout);
   qDebug() << "awaited";
   cr.changeColor();
}

Да, "не блокируется", просто в строке co_await происходит return (специфический), а строка awaited выполнится когда корутину опять позовут, кто и когда - дело вызывающего.

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

C++ (Qt)
bool MyFilter::eventFilter( QObject * obj, QEvent * e )
{
   switch (e->type()) {
     ...
     case QEvent::MouseMoved:
       m_drag.resume(); 
       return true;
    ...
   }
}

Где m_drag - член класса фильтр, хендл на корутину, как его делать - не знаю, найду подобное и перепишу. Теперь сам драг

C++ (Qt)
void MyDrag( void )
{
 ...
 while (true) {
  ...
  co_yield;    // ждем пока не вызовет одно из событий
 
// тело драга
  QPoint pt = GetMousePosition();
  if (pt == oldPt) continue;
  DoDrag(pt);
  oldPt = pt;
 }
}
}

Верно ли я мыслюсь?  Если да, то как передать в корутину QEvent * e ?

Чувак же неоднократно говорил что запись будет на ютубе, что непонятно, можно пересмотреть. Я вообще смотрю видео на скорости 1.5 потому что люди оч медленно говорят. А почитать очередной слайд можно и на паузу нажать.

За что борются классы в с++? За что борются шаблоны? Разработчики шаблонов вредил могли подумать о том что люди будут использовать их в метапрограммировании, они задумывались как "генерики".
Примеров использования корутин масса, некоторые он перечислил - генераторы, бесконечные последовательности, ленивые вычисления. Многое из этого есть в питоне, да даже в убогом TCL есть корутины. Серьезно, пощупайте питон, генераторы, async/await.
Основная идея - это "линеаризация" асинхронного кода так чтобы он выглядел синхронно - на каждом "синхронном" вызове мы просто уходим в эвентлуп и возвращаемся когда пришло нужно событие. Вместо лапши хендлеров эвентов, коллбэков или сигнал-слотов получаем простую последовательность действий как если бы мы писали синхронно. Но ожиданий и блокировок нет - код максимально производительный. Всё это требует поддержки библиотеками, конечно, boost asio и QTcpSocket придется переписать.

У меня есть более интересная задача - написать клиент к qbs session на корутинах. Но даже на мою задачу у меня нет времени/желания (я лучше прибухну и в комп поиграю), а вы хотите "готовое и на блюдечке".


Есть https://github.com/lewissbaker/cppcoro, что-то должно войти в станларт с++23. Но, понятное дело, Qt там не уважают (точнее, Qt не делает ровно ничего чтобы пихать свои наработки в стандарт - у них даже есть чел в комитете но никто не обращался к нему с пропозалом или идеей что-либо стандартизовать), так что связку придется писать самому в любом случае. Ну или подождать 5 лет когда Qt снизойдет до поддержки с++20. Ну как QList::toStdVector только посложнее.

Этот код все такой же синхронный - пока вы крутите этот луп вы не можете заниматься другими делами (не привлекая треды). Вообще файловое ИО пример отвратительный, так как в том же линуксе нет неблокирующего файлового ака completion port - вам надо самому городить огород на тредах чтобы их реализовать.
Сокеты - другое дело - пока вы "ждете" нового чанка данных, вы можете "ждать" чанк на другом сокете или новых клиентов. И вам не нужны треды и все проблемы связанные с ними - вы пишите такой же последовательный код как при блокирующем ИО но он магически становится неблокирующим за счет простого использования co_await (await в питоне)

На cppreference пример с resume() в другом треде, на хабре пример с консьюмером\продьюсером (правда у него там рейс о чем я ему сообщил в комментариях, там же более (не вглядывался) правильный вариант).
Но это всё обычно не нужно! Треды придумали не от хорошей жизни а от того что корутин не было.
Треды - вытесняющая многозадачность (ОС решает за вас когда переключать контекст). Корутины - кооперативна многозадачность, когда переключать контекст решаете вы сами. Как минимум плюс в том что контекст можно переключать реже. Например, я в Яндексе написал качалку на питоне (когда asyn/await еще не было) на "зеленых" тредах - 10к файлов качала за полчаса, тупая реализация "в цикле" без тредов имела ETA около недели. То есть без системных потоков можно получить тот же результат что и с ними, только не надо ничего синхронизовывать. Профит! Конечно, оба подхода можно комбинировать.

Примерно такой же как между функтором и лябмдой - писать меньше. Да, вы можете написать итератор который хранит std::function, сами делать сохранение контекста и переход к следующей "итерации"... А можно просто написать yeild в цикле.

Кто вам сказал? Обычная функция, просто return type специфический.
Переключение контекста в тредах больше + нужна синхронизация, а тут не нужно.

Вы можете потратить больше времени на оптимизацию, так как оно освободилось потому что не надо писать лапшу коллбеков. Пайплайн лучше видно.


Ну не успели стандартизовать библиотеку для корутин. Скажите спасибо что основную машинерию дали и теперь люди могут играться с ними - глядишь новые юзкейзы (которых нет в cppcoro) откроют.
Простейшие случаи (generator, lazy) будут в следующем стандарте, сейчас можно юзать cppcoro и не париться - возвращаете generator, пишите цикл с co_yeild и вуаля.
В остальном необходимость писать resumable проистекает из расширяемости и настраиваемости. В питоне вы не можете написать lazy (там вообще корутины не расширяемые), а на плюсах - можете. async/await ждали десяток лет, они работают только с эветлупом. Продьюсер-консьюмер на тредах с корутинами вы не напишите в питоне, а на плюсах - запросто. И тд...

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

И вот важный момент. В примере с драгом корутина смотрится гораздо выгоднее чем вторичный eventLoop с помощью processEvents. НО основные проблемы (которые жрут 95% времени) все те же. В любом случае упр-е отдается "в неизвестность", и что там произойдет - хз. Напр замочили структуры куда корутина пишет. Часто это охраняют модальным диалогом (товарищ в этой теме упоминал). Хотя какая тогда это многозадачность?
Или замыкать фоновую задачу так чтобы она ни с кем не конфликтовала. Но головняк остается - и капитальный. Напр вот баг который я так до конца и не исправил:

- Есть окно, отображает содержимое загруженных данных в виде списка. Юзер решает их перегрузить данные из файла. Ладно, грузим файл, показываем модальный прогресс. И вот в процессе загрузки прорывается событие рисования окна (хотя setUpdatesEnabled = false). Конечно оно лезет к "недогруженным" данным и вылетает. И что делать? "Надо было загрузить данные в др место, а по окончании загрузки все заменить". Так это может оказаться нереальным, да и трудоемкость такого решения очевидна.

Поэтому я бы все-таки корутины не переоценмвал. И, простите мою навязчивость, но все же