Presenter – это связующее звено между View и Model.
Может, Proxy[Link] – это связующее звено между View и Model. :)
Можно избавиться от цикла while() в методе QThread::run(), используя QStateMachine. Заодно, получить расширенные возможности создания точек выхода из рабочего потока по n-количеству условий.
Т.е. лично моя позиция — даже если нам приходится использовать Qt для GUI, то только для этого его и надо применять, а всё остальное реализовывать независимыми средствами.
Таким образом, вам придётся набирать несколько сотрудников (вместо одного Qt-эшника) для реализации проекта. Современные IT-технологии позволяют «расслабиться» в плане ресурсов и скорости. Это — «минус». «Плюс» — единая платформа разработки и снижение себестоимости проекта.
Это — так, размышления. :)
Было бы неплохо, если бы вы об этом создали статью. Я бы добавил в «Избранное». Видел стройное решение по конечным автоматам на google-разработка на boost.
Кстати, в сети очень мало и разрозненно упоминается работа с boost применительно к каким-либо технологиям. Для начинающих было бы очень полезно!
Требования кросcплатформенности есть, но я не могу тащить всю свою библиотеку (libFWGUI, libFWDtatbase, libFWCore...)! :)
Повторю, статья для тех, кто работает, именно, с Qt.
Я обращался статьёй к Qt-эшникам. В самом начале упомянул о boost. К тому же, есть у меня собственные наработки на ANSI C с использованием pthread функций. Вариантов — куча, умных и талантливых людей — и подавно. Статься создана для одной веви разработок — Qt Framework. Хотелось донести идею: вдруг кто-то найдёт для себя какое-то новое решение.
Без сомнения. К тому же, напрямую работать с драйвером *.sys, зачастую, невозможно, Приходится пользоваться zadig для конвертации.
Однако, многие применяют libusb (исходники библиотеки можно поправить), В статье отражён пример. Плюс, хотелось обратить внимание на работу с контекстом libusb.
Для объектов, созданных в некотором потоке, не имеет смысл вызывать moveToThread, потому что они по умолчанию уже принадлежат этому потоку. Кроме того, если вы переопределяете QThread::run и не запускаете event loop (а в реализации по умолчанию он запускается), то moveToThread теряет смысл, потому что единственное, на что он влияет, — в каком потоке будут вызываться обработчики событий и слоты объекта, а при отсутствии event loop в потоке они вызываться не будут вообще.
Вроде, это и так понятно… Всё таки, плохо я излагаю мысли. Слава богу, что пишу редко :).
Основная идея всей этой статьи — показать возможную удобную альтернативу безблокировочному доступу к общим ресурсам для потоков.
Буду материал дорабатывать дальше.
Спасибо, что обратили внимание на тонкости разработки потоков. Копну глубже.
Кстати, не применить ли вам для своей темы конечные автоматы и потки, скажем, для сканирования каталогов? Автомат отрабатывает эвенты, это может здорово пригодиться.
Спасибо за обстоятельный комментарий.
По первому абзацу отвечу, что цель статьи — показать возможность применения конечных автоматов для управления жизненным циклом потока.
Важна была идея. Возможно, кто-то увидел для себя решение.
Например, Вы комментарием подсказали читателям направление более основательно изучения всех трёх составляющих, и это — здорово!
Работу с libusb выбрал как пример, на котором проверил материал.
Так же эту технологи. использую для себя при сканировании каталогов на обновление файловой системы, применяю при работе с подключениями к QDatabase.
С фразой получилось «корявенько». Для объектов стека метода run() не имеет смысла применение moveToThread(), т.к. это — переменная метода (возможно, я чего, то не понял).
Указатели нельзя физически (если, конечно, не применить memmove()) переместить в другой поток: память у потоков общая, да и не имеет смысла. Вроде, это видно из исходников QT. Речь идёт о смене владельца указателя.
По третьему пункту: Thread_helper позволяет удалить объект потока простым delete вызвав дестуктор объекта потока и остановив конечный автомат. В коде деструктора класса потока есть quit() и т.д.
Здесь, в выступлении Кармака, мне кажется, есть ещё один сильный аспект: человек оглянулся, пересмотре свой путь, взглянул со стороны, и делится размышлениями об ОТВЕТСТВЕННОСТИ программиста.
Жаргонно, думаю, аналогично высказыванию «за базар нужно отвечать». Так и с программами.
Может, Proxy[Link] – это связующее звено между View и Model. :)
Можно избавиться от цикла while() в методе QThread::run(), используя QStateMachine. Заодно, получить расширенные возможности создания точек выхода из рабочего потока по n-количеству условий.
Таким образом, вам придётся набирать несколько сотрудников (вместо одного Qt-эшника) для реализации проекта. Современные IT-технологии позволяют «расслабиться» в плане ресурсов и скорости. Это — «минус». «Плюс» — единая платформа разработки и снижение себестоимости проекта.
Это — так, размышления. :)
Кстати, в сети очень мало и разрозненно упоминается работа с boost применительно к каким-либо технологиям. Для начинающих было бы очень полезно!
Повторю, статья для тех, кто работает, именно, с Qt.
Однако, многие применяют libusb (исходники библиотеки можно поправить), В статье отражён пример. Плюс, хотелось обратить внимание на работу с контекстом libusb.
Вроде, это и так понятно… Всё таки, плохо я излагаю мысли. Слава богу, что пишу редко :).
Основная идея всей этой статьи — показать возможную удобную альтернативу безблокировочному доступу к общим ресурсам для потоков.
Буду материал дорабатывать дальше.
Спасибо, что обратили внимание на тонкости разработки потоков. Копну глубже.
По первому абзацу отвечу, что цель статьи — показать возможность применения конечных автоматов для управления жизненным циклом потока.
Важна была идея. Возможно, кто-то увидел для себя решение.
Например, Вы комментарием подсказали читателям направление более основательно изучения всех трёх составляющих, и это — здорово!
Работу с libusb выбрал как пример, на котором проверил материал.
Так же эту технологи. использую для себя при сканировании каталогов на обновление файловой системы, применяю при работе с подключениями к QDatabase.
С фразой получилось «корявенько». Для объектов стека метода run() не имеет смысла применение moveToThread(), т.к. это — переменная метода (возможно, я чего, то не понял).
Указатели нельзя физически (если, конечно, не применить memmove()) переместить в другой поток: память у потоков общая, да и не имеет смысла. Вроде, это видно из исходников QT. Речь идёт о смене владельца указателя.
По третьему пункту: Thread_helper позволяет удалить объект потока простым delete вызвав дестуктор объекта потока и остановив конечный автомат. В коде деструктора класса потока есть quit() и т.д.
Спасибо за поправку к исключениям. Буду думать…
Жаргонно, думаю, аналогично высказыванию «за базар нужно отвечать». Так и с программами.