Надо объединить не-Qt приложение с функционалом на Qt.

[Гурман]

Есть некое приложение, которое чего-то делает, управляет некоторой аппаратурой, для чего передает и принимает байты различными способами, через кабели, разные интерфейсы и т.д. Надо снабдить его возможностью делать тоже самое через 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-приложения, чтобы дать грамотную рекомендацию. Просто тут у меня случай, когда одна голова - хорошо, но лучше бы ещё парочку.

[Bepec]

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

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

[Igors]

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

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

[Гурман]

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

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

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

[Гурман]

Портировать "взад" - ну а нужно ли?

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

[Old]

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

[Гурман]

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

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

[Old]

чем каждый раз переделывать, лучше заложить возможность расширений

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

[Гурман]

Программа использует нативные средства, и сетевые функции гармонично туда добавляются.

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

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

[Old]

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

Простите, мы говорим про:

мне надо для него сделать только 4 функции - установить соединение с устройством, передать байт, принять байт, разорвать соединение с устройством.

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

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

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

[Гурман]

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

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

(потратим на это месяц и напишем отдельную библиотеку для этого).

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

[xokc]

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

[Гурман]

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

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

Код:

#ifndef WRAPPERS_H
#define WRAPPERS_H

extern int initConnection( char* ip, char* port, bool test );
extern void sendByte( BYTE byte );
extern BYTE receiveByte();
extern void closeConnection();

#endif // WRAPPERS_H

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

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

[Bepec]

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

[Гурман]

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

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

laninout\release/liblaninout.a(laninout.o):laninout.cpp::-1: error: undefined reference to `_Unwind_SjLj_Register'

и

C:\Qt\2009.03.static\qt\lib/libQtCore.a(qiodevice.o):qiodevice.cpp::-1: error: undefined reference to `_Unwind_SjLj_Register'

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

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

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

НО!

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

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

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