Работа с двумя потоками в qt

Потому что Qt sdk - это не чисто графический toolkit, блин а как хотелось бы, и для удобства использования механизмов Qt sdk - их инструменты (например gtk придумал собственный умный указатель - нахрена не понятно, но приходится пользоваться, Qt - тоже). Да порой решения проектантов Qt странны (например foreach на map выдает не pair<key,value>, а value). Проще говоря - когда будет нормальный графический мультиплатформенный toolkit, без амбиций подмять все под себя - тогда можно и чисто std обмазаться.

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

В Qt все лаконично и удобно. И причем тут лямбды?

Нормальные - это ты? Мудрый разработчик сделает класс на Qt, который будет работать с последовательным портом в одном потоке с GUI. И только в случае необходимости перебросит данный класс в отдельный поток. А не так: о, а давайте ка на потоках лабать…

О. MOC - ненавистники подоспели. Нет никакого «над».

qt 4.7.8

и зачем выбрана именно эта версия ?

будет работать с последовательным портом в одном потоке с GUI

Вот это надо быть реально тупым.

А не так: о, а давайте ка на потоках лабать…

Есть две разные сущности, которые должны работать параллельно. Что я не понимаю в потоках?

Что я не понимаю в потоках?

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

Вот это надо быть реально тупым.

QtSerialPort прекрасно работает без дополнительных потоков «пользователя».

Вот это надо быть реально тупым. QtSerialPort прекрасно работает без дополнительных потоков «пользователя».

Что будет, когда читаешь из порта, а данных еще нет?

QtSerialPort - базируется на классе QIODevice, и занимается отслеживанием прихода данных в порт самостоятельно, когда данные доступны для чтения - испускается сигнал readReady и к нему можно уже прикрутить что угодно, хоть слот хоть вашу любимую лямбду.

Когда в std будет всё,что предоставляет QtCore (нормальная работа с разными кодировками из коробки, например) — тогда можно и чисто std обмазаться.

Починил, не благодари.

спасибо, Вы читаете мысли

А в доке написано:

waitForReadyRead()) to suspend the calling thread until the operation has completed? Т.е. поток будет остановлен вместе с GUI мы ведь в одном ним потоке собираемя работать?

Или (non-blocking) alternative. Operations are scheduled and performed when the control returns to the Qt event loop.

Т.е. я должна дождаться когда будут обработаны все события в GUI а это может быть сотни миллисекунд и поимтересоваться насчет данных. А данные уже другие а старые уже потеряны а поезд уехал а люди остались.

Какие проблемы с кодировками в 21 веке с С++?

А вы точно понимаете что есть UART?

Я понимаю что написано про QtSerialPort и проблемы которые при этом возникают.

Скажите, а как можно с помощью сигналов и слотов передать структуру данных?

qRegisterMetaType<MyStruct>("MyStruct");

QObject::connect(sender, SIGNAL(structReady(MyStruct)), receiver, SLOT(acceptStruct(MyStruct)));

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

А данные уже другие а старые уже потеряны

И часто такое случается? А если всё в отдельном потоке, но у ОС найдётся другой важный процесс на пару сотен миллисекунд вместо нашего чтеца, данные тоже уйдут? И как тогда вообще общаться с серийным портом?

Меня ещё в начальной школе учили, что обозначения уровня «плохо» и «хорошо» - это уровень детского сада. Что именно плохого?

нет не понимаете, потому что не понимаете как работает

другой важный процесс на пару сотен миллисекунд

Если это будет часто то работать вообще ничего не будет, даже мышь.

Работа с двумя потоками в qt (комментарий)

Что не понимаю?

Как работают прикладные программы с физическими устройствами UART в операционных системах, если б понимали - то вопроса о блокировке и потери данных у вас бы не возникло.

Для самых тугих поясняю, qt event loop блокируется и даже буфер вас не спасет от фиаско.

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

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

Вот это надо быть реально тупым.

Ты серьезно думаешь, что уже знаешь предмет настолько, что можешь уже оскорбления писать?

Есть две разные сущности, которые должны работать параллельно. Что я не понимаю в потоках?

Наличие разных сущностей не дает обязательности потоков.

Не очень понял твою позицию, ты за отдельный поток для чтения/записи в последовательный порт или нет?

Ничего не будет. При асинхронной работе твой слот просто не будет запущен.

При работе с последовательным портом в асинхронном режиме нужно использовать сигнал readyRead().

Ты плохо изучила документацию. Нужно работать с портом асинхронно.

Или тут речь идет про датчики. Я картиночки все красиво перерисовала, окошечки подвигала, полы помыла, освободилась и побежала посмотреть «а что у нас на кухне»? А там уже плиту залило а кошки все мясо сожрали.

Если твой преподаватель говорит, что инструмент, который используется повсеместно в продакшене костыль, при том что сам толком не знает Qt, то велика вероятность, что он не компетентен.

Асинхронно, Карл!!!

А чем отличается приход события в eventloop от поллинга флага «есть сообщение от serial port» в таком случае? И то, и другое не делается посреди «двигания окошек», задержка в любом случае будет.

поллинга флага делается в другом потоке, который не блокируется GUI. Т.е. подружка сидит на кухне и следит за плитой и кошками.

Работа с двумя потоками в qt (комментарий)

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

А с хрена ли он будет писаться быстрее чтения?

Работа с двумя потоками в qt (комментарий)

performed when the control returns to the Qt event loop

Это будет когда я поток освобожу? Правильно? А освобожу когда полы помою, окошки перерисую и т.д.

И вот, гений архитектуры, ответь пожалуйста, вот будет у тебя шина RS-485 и 20 подключенных устройств. Ты 20 потоков будешь делать?

Это будет когда я поток освобожу? Правильно? А освобожу когда полы помою, окошки перерисую и т.д.

Ну, удиви противоречиями.

Считает программа. Каждая итерация - 2000 миллисекунд.

В гуи-то вообще никак ничего не попадает, что ли?

Если у тебя расчет 2000мс, то он тебе gui подвестит безо всякого порта. Такой расчет нужно оптимизировать или внутри его итераций дергать обработку Qt событий или этот расчет в другой поток кинуть, но только если это действительно целесообразно.

Зачем 20, достаточно 2. Поток не блокируется, опросила по очереди, считала с тех кто готов, запустила поток на обработку и по по новой опрашивать.

Кто мешает организовать обмен данными между потоками через разделяемый объект?

внутри его итераций дергать обработку Qt событий

Плохая идея, на самом деле. Логика программы легко может поломаться от неявных рекурсивных вызовов.