Здравствуйте, Shmj, Вы писали:

S>... И эта система событий при последовательных n-запросах выглядит уродски — ...
S>Можно ли как-то это все сделать красиво, типа Task/Promises заюзать, чтобы выглядело все как последовательный вызов методов а не прыжки?

Пример на корутинах:
https://github.com/danvratil/qcoro#qnetworkreply
Один в один то что искалось — следующий http запрос зависит от содержимого результата предыдущего. Результирующий код выглядит последовательно, а не как асинхронное спагетти.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Проблема асинхронной лапши присутствует в полный рост в любой асинхронной библиотеке/фреймворке. Переход на голый Asio сам по себе не поможет с выпрямлением кода — там будет ровна та же лапша.
EP>Во всех современных языкаx проблема выпрямления асинхронщины решается с помощью корутин представленных в том или ном виде (await/co_await, call/cc, библиотечные корутины а-ля Boost.Coroutine).
EP>В то же Asio именно корутины и предлагаются в качестве решения (будь-то stackless макросы, stackful клей к Boost.Coroutine, либо клей к корутинам C++20).
Да, и если для asio я видел варианты await/co_await, то для QNetworkAccessManager-a не видел, поэтому и предложил от Qt-a оставить только UI, и перейти на более распространенную библиотеку. QNetwork в Qt-e это то еще чудовище, они только 1-2 года назад сделали timeout для запросов, до этого надо было самому делать.

Здравствуйте, Shmj, Вы писали:

EP>>Это одно из главных применений корутин — синтаксически выпрямлять асинхронный код.
S>А есть ли пример как сигналы преобразовать в корутины?

Первый же результат гугла на "QT coroutine" выдаёт решение сабжевой задачи:
https://github.com/danvratil/qcoro#qcoro---coroutines-for-qt5-and-qt6

Вопрос такой. QT по умолчанию юзает системы событий, по сути (сигналы, слоты). И эта система событий при последовательных n-запросах выглядит уродски — в одном методе отправляете, потом в другом ловите, потом там опять отправляете и разве что switch или типа того использовать, чтобы понять какой ответ мы обрабатываем.

Можно ли как-то это все сделать красиво, типа Task/Promises заюзать, чтобы выглядело все как последовательный вызов методов а не прыжки?

Здравствуйте, m2user, Вы писали:

M>На каком решении ты в итоге остановился?
M>Что-то из предложенного тут (Последовательные HTTP-запросы — как сделать красивее?) или сторонняя библиотека корутин (QCoro и пр.)?

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

Здравствуйте, Igore, Вы писали:

S>>Можно ли как-то это все сделать красиво, типа Task/Promises заюзать, чтобы выглядело все как последовательный вызов методов а не прыжки?
I>либо вообще отказаться от Qt для сети и перейти на boost::asio, boost::beast,

Проблема асинхронной лапши присутствует в полный рост в любой асинхронной библиотеке/фреймворке. Переход на голый Asio сам по себе не поможет с выпрямлением кода — там будет ровна та же лапша.
Во всех современных языкаx проблема выпрямления асинхронщины решается с помощью корутин представленных в том или ном виде (await/co_await, call/cc, библиотечные корутины а-ля Boost.Coroutine).
В то же Asio именно корутины и предлагаются в качестве решения (будь-то stackless макросы, stackful клей к Boost.Coroutine, либо клей к корутинам C++20).

Здравствуйте, Shmj, Вы писали:

S>Вопрос такой. QT по умолчанию юзает системы событий, по сути (сигналы, слоты). И эта система событий при последовательных n-запросах выглядит уродски — в одном методе отправляете, потом в другом ловите, потом там опять отправляете
Тут всё правильно
S>и разве что switch или типа того использовать, чтобы понять какой ответ мы обрабатываем.
А вот тут непонятно, сделай разные слоты и не мучайся

S>Можно ли как-то это все сделать красиво, типа Task/Promises заюзать, чтобы выглядело все как последовательный вызов методов а не прыжки?
Можно, либо написать что то своё, тут что то похожее обсуждалось, не могу найти, выглядело как то так, run([]).except([]).then([]).except([]).then([]), либо через свой QEventLoop(exec), либо "синхронно"(while(!isFinished()) processEvents()) ждать окончания запросов, либо если сокеты waitFor* методы, либо вообще отказаться от Qt для сети и перейти на boost::asio, boost::beast, curl или что другое.
Встроенных средств не встречал, либо напиши своё, либо прими архитектуру.

Здравствуйте, Shmj, Вы писали:

S>Можно ли как-то это все сделать красиво,
Можно. Просто сделать connect на разные методы для разных запросов.

S> типа Task/Promises заюзать, чтобы выглядело все как последовательный вызов методов а не прыжки?
Не советую, так как не думаю, что вы умеет корректно передавать Qt-объекты в другие нити.

Здравствуйте, Shmj, Вы писали:

S>И эта система событий при последовательных n-запросах выглядит уродски — в одном методе отправляете, потом в другом ловите, потом там опять отправляете и разве что switch или типа того использовать, чтобы понять какой ответ мы обрабатываем.

слот не обязательно должен быть отдельной функцией, можно прямо в connect() запихать лямбду, будет в одном месте.

d http-header можно свои кастомные поля запихивать, по ним в принципе можно узнать, какой ответ к чему относится

Здравствуйте, wl., Вы писали:

S>>И эта система событий при последовательных n-запросах выглядит уродски — в одном методе отправляете, потом в другом ловите, потом там опять отправляете и разве что switch или типа того использовать, чтобы понять какой ответ мы обрабатываем.

wl.>слот не обязательно должен быть отдельной функцией, можно прямо в connect() запихать лямбду, будет в одном месте.

Но лесенкой. А представьте если еще и условия будут — если не такой ответ, то запрос другой или повторить тот или иной запрос...

Здравствуйте, Shmj, Вы писали:

S>Вопрос такой. QT по умолчанию юзает системы событий, по сути (сигналы, слоты). И эта система событий при последовательных n-запросах выглядит уродски — в одном методе отправляете, потом в другом ловите, потом там опять отправляете и разве что switch или типа того использовать, чтобы понять какой ответ мы обрабатываем.
В общем случае лучше делать машину состояний.

Здравствуйте, Shmj, Вы писали:

S>в одном методе отправляете, потом в другом ловите, потом там опять отправляете и разве что switch или типа того использовать,
S>Можно ли как-то это все сделать красиво, типа Task/Promises заюзать, чтобы выглядело все как последовательный вызов методов а не прыжки?

Это одно из главных применений корутин — синтаксически выпрямлять асинхронный код.
В stackless реализациях await, часто именно switch под капотом и используется — автоматически, без рукопашной нарезки состояний на case'ы.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Это одно из главных применений корутин — синтаксически выпрямлять асинхронный код.
EP>В stackless реализациях await, часто именно switch под капотом и используется — автоматически, без рукопашной нарезки состояний на case'ы.

А есть ли пример как сигналы преобразовать в корутины?

S>Можно ли как-то это все сделать красиво, типа Task/Promises заюзать, чтобы выглядело все как последовательный вызов методов а не прыжки?

На каком решении ты в итоге остановился?
Что-то из предложенного тут (Последовательные HTTP-запросы — как сделать красивее?) или сторонняя библиотека корутин (QCoro и пр.)?

Здравствуйте, m2user, Вы писали:

S>>Можно ли как-то это все сделать красиво, типа Task/Promises заюзать, чтобы выглядело все как последовательный вызов методов а не прыжки?

M>На каком решении ты в итоге остановился?
M>Что-то из предложенного тут (Последовательные HTTP-запросы — как сделать красивее?) или сторонняя библиотека корутин (QCoro и пр.)?

Не занимайтесь некрофилией со старыми темами. По всем постам Шимжи в технических темах очевидно, что он задаёт вопрос только чтобы его задать, а не получить ответ. И пока не было нигде подтверждения того, что он вообще умеет нормально программировать и как-то использует ваши ответы. Человек просто развлекается.

Здравствуйте, Shmj, Вы писали:

S>Можно ли как-то это все сделать красиво, типа Task/Promises заюзать, чтобы выглядело все как последовательный вызов методов а не прыжки?

Пиши на Go. Там всё последовательно.

Здравствуйте, Kernan, Вы писали:

K>В общем случае лучше делать машину состояний.

Её надо уметь делать. Иначе сложно очень.

Кстати, а что ты думаешь, по поводу мнения (http://rsdn.org/forum/cpp.qt/8445892

Автор: Igore
Дата: 10.01.23

), что QT следует оставить только для UI, а для работы с сетью взять boost.asio и т.п.?

Здравствуйте, m2user, Вы писали:

M>Кстати, а что ты думаешь, по поводу мнения (http://rsdn.org/forum/cpp.qt/8445892

Автор: Igore
Дата: 10.01.23

), что QT следует оставить только для UI, а для работы с сетью взять boost.asio и т.п.?

Я бы пошёл еще дальше: оставил бы Qt для гуйни, а всё остальное сделал бы на Go.

Здравствуйте, Shmj, Вы писали:

S>Вопрос такой. QT по умолчанию юзает системы событий, по сути (сигналы, слоты). И эта система событий при последовательных n-запросах выглядит уродски — в одном методе отправляете, потом в другом ловите, потом там опять отправляете и разве что switch или типа того использовать, чтобы понять какой ответ мы обрабатываем.

S>Можно ли как-то это все сделать красиво, типа Task/Promises заюзать, чтобы выглядело все как последовательный вызов методов а не прыжки?

Я через сигналы и слоты делал CompletableFuture, типа как в джаве, и всё было очень красиво