Руководство поручило вместо boost::asio использовать Qt

А в чём именно тебе нужен совет? Просто бери и переписывай. В простых случаях там всё тривиально.

Очевидно - глянуть в сорцы/доку. Если оратор не прав - прилюдно его унизить с пруфами и особым цинизмом. Иначе - харасмент.

Компромисный вариант - перейти на пайтон.

Классы Qt очень приятны. Но не собираются ли Qt-шники отказываться от своих классов в пользу boost/stl, или даже к сигналам слотам из boost? Чето я такое слышал, может это была новость 1 апреля

Но это в будущем, а сейчас классы Qt есть, и они прекрасны. Юзай, сын мой, советую так и поступить

Раньше тоже так думал. Вот архитектурно - Qt местами торт. Но api там вырвиглазное, слишком джавовое что-ли. Взять QList с operator [] и реализацией на векторе.

Но api там вырвиглазное, слишком джавовое что-ли.

Вкусовщина или есть конкретные примеры? C++ std в миллионы раз хуже. Я молчу про буст.

Мне казалось QtNetwork и boost::asio в разных весовых категориях. Qt намного удобнее, но доступ к внутренностям закрыт.

Значит ты не умеешь его готовить, если пользоваться через анал, то Qt конечно будет неудобным, а если грамотно - то всё будет красиво и удобно

C++ std в миллионы раз хуже. Я молчу про буст.

Лол, а парни то и не знали :)

Вкусовщина или есть конкретные примеры?

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

Qt - для написания UI в первую очредь, всё остальное там по остаточному принципу, достаточно что бы на уровне прототипа или простых случаев не тащить другие зависимости. И это грамотно.

Но если речь идёт уже об отсутсвии/наличии epoll то я бы просто сравнил бы io_service::run и QEventLoop::run, поплевался бы и взял буст.

Вкусовщина, многобукав, инопланетно, нет исключений...

В целом согласен. В данном случае не покидает ощущение использования инструмента не по назначению... GUI toolkit - это одно, а epoll-based asynchonous event loop for I/O programming - это совершенно другое. Но, видимо, надо смириться... :)

Наверное, индексацией вектора int-ом хуже(хоть unsigned бы для приличия взяли)

Загугли why qlist is bad

Сами qtшники его не рекомендуют юзать

Я его и не использую. Но сам Qt на него завязан. Ничего не поделаешь.

Думать о безопасности в сишке? Но зачем?

Qt - для написания UI в первую очредь, всё остальное там по остаточному принципу

Хоть и недолюбливаю Qt, но это уж толсто.

// Пишу проект, процентов 5 кода с Qt это гуй, остальное - Core, Network, WebEngine. Идет нормально.

// Пишу проект, процентов 5 кода с Qt это гуй, остальное - Core, Network, WebEngine. Идет нормально.

Если не секрет, то как оно в проде себя ведёт? Держит ли нагрузку? Грузит ли все головы всех процов при этом? Можно ли сетевое решение не Qt так же легко скэйлить по кол-во thread-ов, как сделанное на `asio::io_service` - просто добавив thread-ов и вызвав в них `io_service::run()`?

Для «почтового ящика» естественно желание максимально упрощать код. Я бы тоже буст не пропускал, если Qt хватает. Кто после тебя сопровождать будет? Видел я, какие кадры в таких конторах.

Я бы тоже буст не пропускал, если Qt хватает. Кто после тебя сопровождать будет?

Удваиваю этого адеквата.

Для «почтового ящика» естественно желание максимально упрощать код. Я бы тоже буст не пропускал, если Qt хватает. Кто после тебя сопровождать будет? Видел я, какие кадры в таких конторах.

Согласен! Это было разумным аргументом руководства. Я сам не уверен, поэтому и спрашиваю... Разумом всё понимаю, но «сердцем» - нет. Да и не сильно там в этом boost::asio и много чего этакого - день на изучение да игрища с примерами и можно кодить, если «по чесноку»...

И ещё возникает мысль: Может пришла пора заняться кадрами, а не идти на такие компромиссы, делая «закладки на будущее»? Вот и пусть люди обучаются разным технологиям - на практике лучше всего познание идёт...

Нет, за нагрузки не скажу. На Qt у нас очень легкий сетевой обмен, тяжелый вынесен на webrtc.

А что советовать. QTcpSocket и вперед.

Ключевое словом тут webengine, в этой теме я плаваю, но вроде альтернатив Qt тут не так уж и много и их реализация прибита гвоздями.

Начать надо да, с требований. Если они есть, особенно нефункциональные то исходить строго из них. Если 99% это ui и надо 3 файла раз в три года принять по сети, то делать асинхронную кракозябру на пустом месте смысла не имеет.

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

для многопоточного I/O

во-первых, а имеется ли реальная потребность в epoll? мои знакомые телепаты все в отпуске, поэтому я не знаю, от каких аргументов отталкиваться чтоб объяснить почему Qt не замена asio/libev/libuv.

если что-то сильно нагруженное, то прямо ткнуть мордой в QObject.moveToThread и объяснить, что Qt не для многопоточной обработки, он для гуя. там нет распределения запросов по потокам.

а что плохого то? небольшие листы на векторе делать и надо, оно тупо быстрее.

Речь про https://think-async.com/Asio/ , который может быть и без буста.

Я конечно понимаю, что кому-то буст поперек горла, да и укушенных александреску было много в свое время. Но сейчас то, в 2019м, не уметь писать на C++, и выкидывать буст по сомнительным мотивам - это позор. (Относится только к называющим себя С++ программистами, остальным это и не нужно, да).

какие кадры в таких конторах.

Таким кадрам CPP совсем нельзя давать. Накрутят 100500 уровней наследования, да еще и множественного, такой трындец, сами через полгода в этом утонут.

Ну как бы для этого надо понимать, что такое общий и частный случай, что такое асимптоматическая сложность и почему и когда O(n) лучше чем O(logn). А так человек всегда использует листы на векторе и обычно у него все работает, а вот тут какая-то хрень получается. Такое регулярно встречается. В тех же почтовых ящиках где код пишется не программистами зачастую, а инженерами других специальностей.

кто потребовал из контекста непонятно
но очевидно что куте это не про сетевую разработку
может куте для написание меил клиентов? тогда ок

в случае гуя «частный случай» на практике является общим, а общий - частным.

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

во-первых, а имеется ли реальная потребность в epoll?

Хороший вопрос! Полагаю, что да. Системы тестируются под хорошими нагрузками: много I/O, узлов, сокетов. Надо, чтобы I/O работало как часы и не зависело от скорости отрисовки ГУЯ.

Что посоветуете? :) Благодарю!

Потребовать прибавку к з/п из-за изменившегося стека технологий, который тебе предстоит осваивать.

Пусть работодатель оплатит свои капризы сам.

Что посоветуете? :)

https://pp.userapi.com/LsvOsZztFkpN5QyolvAKTEFFNApEFFWETrO62A/Ns0hoy33lhk.jpg

На вопрос «а как же epoll()» был получен ответ, что «QDataStream его поддерживает»

Что посоветуете?

Делать ноги

был получен ответ, что «QDataStream его поддерживает»

Вряд ли вам там скорость нужна, видимо простота поддержки в приоритете.

DataStream медленный, на каждое считываемое поле идет аллокация памяти, если это не plain структуры. Иногда только здесь можно ускорить раза в 4.

QTcpServer даже не reentrant, строго с одного потока всё, т.е. даже мютексы не помогут. В сравнении с системными send\recv которые можно, например, вынести в два потока для tcp.

С виду 10 лет ничего не меняется.. но под капотом по мелочи постоянно что-то переписывают/ломают. Тормозной трекер придется почитывать https://bugreports.qt.io/browse/QTBUG-77365?jql=project = QTBUG AND component...

но это все эти проблемы останутся незамеченными если настоящих нагрузок нет

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

А еще забыл добавить. Неконтролируемый буфер записи у сокета. Можно узнать сколько реально отправилось только подписываясь на bytesWritten() для каждого сокета, иначе при больших объемах отправки эти гигабайты будут в памяти накапливаться, вплоть до крэша.

асимптоматическая сложность

Какая???

Да ладно, раньше тут помнится было принято советовать сделать вдоль. Лорчик добрый

ну бывает)

Сейчас за это содют.

Вряд ли вам там скорость нужна, видимо простота поддержки в приоритете.

Ещё как нужна! :) см выше:

Системы тестируются под хорошими нагрузками: много I/O, узлов, сокетов. Надо, чтобы I/O работало как часы и не зависело от скорости отрисовки ГУЯ.

Благодарю за инфу про потроха сетевого модуля кутэ!

утраиваю )))

вам подыскивают повод для увольнения
завтра попросят все переписать на луа
а после завтра начальство вычитает на лоре что лисп бог языков
и догадайтесь что вы будете изучать ?

в С++23 asio станет стандартом
и половину куте сами кутешники выбросят на помойку
переучиваться обратно будете ?
если скорость не нужна, запилите на ерланге, че

Значит ты не умеешь его готовить, если пользоваться через анал, то Qt конечно будет неудобным, а если грамотно - то всё будет красиво и удобно

Видимо, подразумевается орал? Будем знать.

Ъ переписал бы на libevent

https://habr.com/ru/post/263549/

Вот этим поди вдохновлялись

я не спец в культе. но попадалось тут недавно на глаза вот такое: http://www.forum.crossplatform.ru/index.php?showtopic=10976

если такое существует в библиотеке, которая разрабатывается уже столько лет - это какбэ очень, очень подозрительно.

Пиши как сказали и не выеживайся.