Вопрос к знатокам Qt и компиляторов

[pastor]

QX11EmbedWidget?

Кстати да. Можно попробывать

[nik135]

to BRE: перечитайте самое первое сообщение. вопрос состоял в возможности сосуществования двух qapplications. а функции для разделяемых библиотек я писать умею.

а что такое x11embedwidget?

[pastor]

а что такое x11embedwidget?

Qt4:
QX11EmbedWidget

Qt3:
XEmbed

[BRE]

to BRE: перечитайте самое первое сообщение. вопрос состоял в возможности сосуществования двух qapplications. а функции для разделяемых библиотек я писать умею.

Я обязательно перечитаю первое сообщение.
Смотрим.
Приложением Qt3.

Код

C++ (Qt)
int main( int n, char **v )
{
    QApplication app( n, v );    // Это QApplication Qt3
 
    // Загружаем библиотеку, резольвим функцию и т.д.
    ...
    // Вызываем функцию из библиотеки.
    libFunc();
 
    app.exec();
}
 

Библиотека Qt4.

Код

C++ (Qt)
void libFunc()
{
    QApplication app( 0, 0 );    // Это QApplication Qt4
    MyDialog dlg;
    dlg.exec();
}
 

Будет работать, но при этом полностью заморозит приложение Qt3 на время выполнения функции libFunc.
Вывод: С большими ограничениями сосуществование двух QApplication-объектов возможно.

[Dendy]

Не вижу никаких технических препятствий одновременного существования двух, трёх, хоть десяти экземпляров QApplication, если они импортируются из разных библиотек. Главное здесь соблести своё пространство имён и строить интерфейс на X11-прослойке. Для Qt3 приложения не существует Qt4, а для плагина неизвестно кто хозяин контейнера. Следовательно - в плагине везде использовать:

Код

C++ (Qt)
using MyQt4Plugin;

Это неймспейс, в который будет завёрнута библиотека Qt4, собраная для этого плагина. Возможно даже статически.

Что касается обработки событий - из интерфейса плагина будет торчать каллбек для обработки сообщений. Основная программа дёргает его по таймеру в главном цикле, а реализация каллбека вызывает QApplication::processEvents(). Потоков это не касается - там свои циклы обработки событий. С блокирующими диалогами это конечно интересно, но думаю всё можно обойти. В крайнем случае - не использовать стиль программирования с блокированием главного цикла.

[BRE]

Тут вопрос больше не в том, как создать несколько разных экземпляров QApplication, а что можно с ним сделать (или а надо ли их вообще создавать). Какой сервис может предоставить библиотека использующая Qt4, программе использующей Qt3?
Конструировать объекты визуальных классов Qt4 - не выйдет (точнее не их получиться использовать).
Остается экспортировать функции, которые будут выполнять определенную работу (+ возможно, использовать widgetы Qt4). Это обсудили раньше.
Обойти замерзание, конечно можно, передавая в функцию например указатель на processEvents и пусть функция сама его дергает, только как то это все извращенно получается.

[nik135]

Тут вопрос больше не в том, как создать несколько разных экземпляров QApplication, а что можно с ним сделать (или а надо ли их вообще создавать). Какой сервис может предоставить библиотека использующая Qt4, программе использующей Qt3?

Тут все дело как обычно, в лени 
Сейчас используется класс и форма с самодельными виджетами для работы с этим классом. Потребовалось использовать все это хозяйство под qt3. Вот и все. А переписывать все это под qt3 очень неохота.

[nik135]

Библиотека Qt4.

Код

C++ (Qt)
void libFunc()
{
    QApplication app( 0, 0 );    // Это QApplication Qt4
    MyDialog dlg;
    dlg.exec();
}
 

Будет работать, но при этом полностью заморозит приложение Qt3 на время выполнения функции libFunc.
Вывод: С большими ограничениями сосуществование двух QApplication-объектов возможно.

По-моему если указывать в качестве параметров нули- ругается, что не может открыть display. В никсах в качестве параметра передается номер дисплея. ИМХО так, по памяти. Завтра обязательно все проверю. Спасибо всем, если завтра не срастется, буду вас опять мучать 

[Tonal]

Есть следующая проблема: нужно использовать виджет от qt4 в qt3. Обе библиотеки существуют на машине параллельно и используют каждая свои glibc, g++ и т.д.
Для решения задачи создаю библиотеку  средствами qt4 и в ней же создаю объект QApplication. Потом к этой библиотеке линкуюсь из qt3. Все компилируется, но не пашет :-( Валится в сегфолт 

Я не спец в linux-е, но не кажется ли уважаемому сообществу, что использование разных версий glibc, g++ и т.д в одном приложении как раз и может приводить к сегфолту?

По крайней мере под виндой попытка работать из проги с dll-кой, если они собраны разными версиями дельфей в динамике приводит к самым неожиданным падениям...
С MSVC я не настолько плотно работал, но подозреваю что и там не всё шоколадно.

[nik135]

Сегодня попробовал и вот че получил:

Если создается QApplication из qt4 до создания QApplication из qt3

Код:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 3117)]
0x40816502 in QMutexPool::get () from .../libqt-mt.so.3     

Если создается QApplication из qt3 до создания QApplication из qt4

Код:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 3238)]
0x412a0ee0 in QApplication::desktop () from .../libQtGui.so.4 

похоже, не могут поделить экран или что-то в этом духе

есть идеи?

[nik135]

По крайней мере под виндой попытка работать из проги с dll-кой, если они собраны разными версиями дельфей в динамике  приводит к самым неожиданным падениям.. .
С MSVC я не настолько плотно работал, но подозреваю что и там не всё шоколадно.

Странно, если следовать твое логике, то версий dll должно быть много - для работы с приложениями на delphi, builder + еще для каждой версии компилятора свои dll и т.д.

ИМХО это не так. dll это машинный код и без разницы, с каким компилятором его использовать, от дельфей или от билдера, или от MSVC.

[Tonal]

Представим, что у нас есть dll с pure C интерфейсом и мы статически слинковали с ней приложение.
Пусть теперь у нас появилась другая версия этой же dll с тем же именем, но другой сигнатурой некоторых функций.
Что произойдёт, если ты запустишь своё приложение?

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

[nik135]

Представим, что у нас есть dll с pure C интерфейсом и мы статически слинковали с ней приложение.
Пусть теперь у нас появилась другая версия этой же dll с тем же именем, но другой сигнатурой некоторых функций.
Что произойдёт, если ты запустишь своё приложение?

А никакой смены-то и не происходит. Есть либа, компиленная одним компилером и есть приложение скомпилированное другим, более поздним. Тогда что плохо?

[BRE]

Сделал тестовый пример, действительно падает.
Причем падает на этапе подключения библиотеки использующей Qt4 (инициализация статических объектов).

Стек после падения (gdb):

#0  0x0297a61c in QMutex::lock () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#1  0x008d3f3b in QAbstractFileEngineHandler::QAbstractFileEngineHandler$base ()
   from /usr/lib/libQtCore.so.4
#2  0x008f9bf0 in QTemporaryFile::QTemporaryFile$base () from /usr/lib/libQtCore.so.4
#3  0x008f9c8b in qInitResourceIO () from /usr/lib/libQtCore.so.4
#4  0x008f9ccd in qInitResourceIO () from /usr/lib/libQtCore.so.4
#5  0x00966566 in QTextCodecPlugin::qt_metacast () from /usr/lib/libQtCore.so.4
#6  0x008883e1 in _init () from /usr/lib/libQtCore.so.4
#7  0x49187ff3 in call_init () from /lib/ld-linux.so.2
#8  0x49188103 in _dl_init_internal () from /lib/ld-linux.so.2
#9  0x4917a84f in _dl_start_user () from /lib/ld-linux.so.2

valgrind:

==15965== Process terminating with default action of signal 11 (SIGSEGV)
==15965==  Access not within mapped region at address 0x0
==15965==    at 0x297A61C: QMutex::lock() (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.
==15965==    by 0x23AF3A: QAbstractFileEngineHandler::QAbstractFileEngineHandler() (in /usr/lib/libQtCore.so.4.3.2)
==15965==    by 0x260BEF: (within /usr/lib/libQtCore.so.4.3.2)
==15965==    by 0x260C8A: (within /usr/lib/libQtCore.so.4.3.2)
==15965==    by 0x260CCC: (within /usr/lib/libQtCore.so.4.3.2)
==15965==    by 0x2CD565: (within /usr/lib/libQtCore.so.4.3.2)
==15965==    by 0x1EF3E0: (within /usr/lib/libQtCore.so.4.3.2)
==15965==    by 0x49187FF2: call_init (in /lib/ld-2.5.so)
==15965==    by 0x49188102: _dl_init (in /lib/ld-2.5.so)
==15965==    by 0x4917A84E: (within /lib/ld-2.5.so)

Конструирует объект QAbstractFileEngineHandler (Qt4), а лочить пытается мутекс из Qt3.
Я библиотеки конечно не пересобирал с разными пространствами имен, вот думаю это проблемы резольвинга символов.

2 nik135: А покажи свой стек возвратов?

[shadone]

Сделал тестовый пример, действительно падает.
Причем падает на этапе подключения библиотеки использующей Qt4 (инициализация статических объектов).

вам надо собрать qt4 в отдельном namespace.

Странно, если следовать твое логике, то версий dll должно быть много - для работы с приложениями на delphi, builder + еще для каждой версии компилятора свои dll и т.д.

именно так. в случае C++ библиотеки будут разные calling convention (даже в рамках разных версий одного компилятора), плюс если библиотека использует runtime library то еще будут проблемы из-за смешения разных рантаймов.