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

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

Здравствуйте, 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-запросах выглядит уродски — в одном методе отправляете, потом в другом ловите, потом там опять отправляете
Тут всё правильно
S>и разве что switch или типа того использовать, чтобы понять какой ответ мы обрабатываем.
А вот тут непонятно, сделай разные слоты и не мучайся

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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).

Здравствуйте, 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 для запросов, до этого надо было самому делать.