Russian Qt Forum

Есть некое приложение, которое чего-то делает, управляет некоторой аппаратурой, для чего передает и принимает байты различными способами, через кабели, разные интерфейсы и т.д. Надо снабдить его возможностью делать тоже самое через IP LAN. Чтобы оно заработало через сеть, мне надо для него сделать только 4 функции - установить соединение с устройством, передать байт, принять байт, разорвать соединение с устройством. Такие функции на Qt через IP у меня давно работают сами по себе. Но родительское приложение стороннее, и написано без использования Qt, просто на С++, сборка CMake (порт из *NIX). Задача несколько облегчается тем, что приложение консольное и есть его исходные тексты. Приложение я импортировал в QtCreator, оно собирается, работает, всё управление устройствами есть, как надо. Теперь вопрос - как дальше объединить имеющийся у меня рабочий сетевой функционал с этим сторонним приложением? Скрестить ежа и ужа... ВАЖНО - крайне желательна, то есть, фактически необходима статическая сборка с Qt (для статики у меня сам Qt давно собран, я таким макаром несколько задач успешно решил). Представляются такие варианты:

1. Сделать динамическую библиотеку, в которую поместить сетевой функционал, приложение доработать с использованием этой библиотеки. То есть, добавить библиотеку в проект приложения, в нем вызывать только нужные мне методы. Можно вообще в библиотеке враппер на C сделать и к нему обращаться в приложении. Удобно тем, что библиотека - отдельный проект, в приложении затрагивается только то, что должно затрагиваться - ввод-вывод. Но не понятно, возможно ли такое вообще, когда библиотека использует Qt, а приложение - нет. Насколько я понимаю, без QApplication нужные мне классы Qt работать не смогут, и пока не вполне ясно, где в таком случае правильнее создавать объект QApplication - возможно ли его создавать в динамической библиотеке, в какой-то функции её инициализации? А получится ли вообще динамическая библиотека со статически скомпонованными в неё функциями Qt?

2. Переделать всё родительское приложение на Qt, а свои классы компоновать в него, не в отдельную библиотеку. Так вроде бы логичнее, но не удобно, поскольку приложение - импортированный CMake проект, а не Qt-проект, управлять этим муторно. И получится, что часть приложения использует только stdlib C/C++, а часть функции Qt. Не вполне ясно, не возникнет ли интерференции. Надо ли переделывать все классы приложения в Q_OBJECT?

3. Вариант - клиент-сервер. Сделать отдельное приложение-сервер на Qt, которое будет заниматься только пересылкой байт, а родительское приложение-клиент обращаться к нему через... Не понятно через что - DDE? RPC? But how? Решение должно работать пока только в Windows, но мало ли... вдруг потом понадобится и в Linux. Родительское приложение портировано из *NIX, Qt тоже мультиплатформенный. Не хотелось бы усложнить возможность обратного портирования.

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

1) Я собственно поднимал тему Qt Dll в не Qt приложениях и вполне успешно.
http://www.prog.org.ru/topic_25323_0.html

PS думаю вполне подойдёт.

Делал вариант 3, UI было 32-bits, а консольная расчетная часть 64. Результатом доволен. Обмен данными организовал через shared memory + 2 семафора. Получается довольно дешево/удобно.

А в данном случае и вариант 2 смотрится очень хорошо. Добавлять Q_OBJECT нет необходимости. Да, придется  повозиться со "сборкой", но это разовые заботы. Портировать "взад" - ну а нужно ли?

Ага. У меня задача проще - приложение не-Windows, без окон,и своих потоков в нем нет. Значит я смело могу запустить QCoreApplication прямо в инициализации при загрузке библиотеки. Либо еще проще - компоновать библиотеку статически, а её инициализацию просто вызвать из main() приложения. Там и QCoreApplication заработает. Библиотека удобнее, так как это отдельный проект, меньше надо проект приложения колбасить. Вроде должно получиться.

Пока не нужно, но может потребоваться.

Почему просто не написать эти 4 функции без Qt?
Для чего тянуть такую жирную зависимость для решения элементарных вещей?

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

Вы сами себя уговариваете? ;)
Что каждый раз переделывать? Программа использует нативные средства, и сетевые функции гармонично туда добавляются. А когда понадобиться добавить морду, тогда и Qt можно добавить. К тому же для морды совсем не обязательно встраиваться в программу, она может использовать в качестве бекэнда консольную программу.

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

этого никто делать не будет

Простите, мы говорим про:
Что там отлаживать? Там кода нативного 100 строк не будет.

Хозяин барин. :)
Вместо добавления нескольких строк кода, будем решать "глобальные проблемы внедрения Qt" (потратим на это месяц и напишем отдельную библиотеку для этого).

Всё отлаживать. Другие функции, другие соединения, другие строки (не QString), другая обработка ошибок == совершенно другой код.


не знаю, у кого месяц... я уже почти написал, и то "почти" только потому, что надо было еще совершенно другими делами заниматься, и внешнее оборудование для отладки сейчас не доступно, поэтому сегодня не успею закончить и проверить - но завтра всё должно заработать  ;)

Если нет страха ещё больше привязаться к Qt, то я бы добавил к основному приложению создание QApplication и вызов модуля из библиотеки/статического плагина. Вариант № 1 в версии, предлагавшейся Вересом, действительно работает, но он всё же немного нечестный хак напоминает.

Страха нет. Но я сделал четвертый вариант - статически компонуемую библиотеку, из которой наружу торчат только 4 враппера:

- это содержимое wrappers.h, как нетрудно догадаться

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

offtop: приятно что кому то помогли мои терзания. :)

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

Все написал, но уперся в сборку... получаю оскоминные сообщения и

и так много-много раз, но только в этих двух модулях

laninout - это моя библиотечка, qiodevice понятно что...

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

НО!

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

библиотеки Qt используются точно те же, собственно, только QtCore и QtNetwork, библиотеки minGW те же... так же не хочется сейчас снова пересобирать Qt в статику

может дело в чем-то другом?

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

А так оно и работает :) По другому сложнее делать :)