[философский вопрос] QT или не QT?
если переписывать, то почему на плюсах? там быстродействие критично?
то есть не будет ли быстрее, если сетевую и счетную часть реализовать в виде библиотек отдельно для линукса(она. можно сказать, уже есть) и отдельно для венды(а вот этого не хотелось бы - вникать в WinAPI не хочется)?Если надо кроссплатформенно сделать только сетевую и счетную часть, зачем вникать в WinAPI? Счетная часть вряд ли что-то чисто линуксовское использует, сетевое API там вроде частично совместимо, частивно есть кроссплатформенные библиотеки готовые. Про межпроцессное взаимодействие в винде плохо знаю, но наверняка и для этого есть готовые библиотеки. Повникаешь в них
не то чтобы совсем критично, но могут возникнуть ситуации когда оно будет востребованным. то есть совсем сбрасывать со счетов нельзя.
а на чем? ну то есть если QT использовать?
а на чем? ну то есть если QT использовать?
не, надо вообще все переносить. поэтому и подумал про QT, что оно умеет вроде как все что нужно, вопрос только насколько быстро и безглючно умеет.
а то придется еще гуй на чем-то виндовом писать, чего совсем не хочется)
щс тестовый кусочек наваял под QT, пока все нравится)
а то придется еще гуй на чем-то виндовом писать, чего совсем не хочется)
щс тестовый кусочек наваял под QT, пока все нравится)
О, я чую холивар. Я за wxWidgets!
Насколько я понял, приложение состоит как минимум из 2 частей:
(1) многопоточное серверное приложение,
(2) клиентское приложение (GUI) для управления.
Я бы переписал Linux-специфичные моменты серверного приложения на кроссплатформенных серверных библиотеках (не QT а GUI - на QT, раз он так нравится.
По серверной части - видимо это pthreads и работа с сетью, так? С pthreads всё просто: берётся библиотека, являющаяся на UNIX/Linux wrapper над pthreads, а на Win32 - wrapper над WinAPI. Таких библиотек сейчас по-моему хватает на любой вкус. Не зная деталей того, как вы работаете с сетью, и какие у вас требования, посоветовать что-то конкретное вряд ли возможно.
Почему не переписать и сервер на QT? Я бы не стал рисковать, переписывая многопоточный сервер на тулките, изначально совершенно не серверном, а клиентском. Потому что есть риск что через некоторое время так сложится, что клиентскому фреймворку (которым является QT) будут малоактуальны ваши серверные проблемы и задачи, и у вас будет выбор: или оставаться на древней версии фреймворка, или существенно дорабатывать новую версию фреймворка (причём, далеко не факт что ваши изменения будут приняты обратно в проект).
У нас так получилось с Mozilla: взяли её из-за NSPR, XPCOM core, движка JavaScript и обвязки XPConnect, прозрачно транслирующей все XPCOM-интерфейсы в JavaScript (т.е. не нужно руками делать JavaScript bindings для каждого нового интерфейса и класса написанного на C++). По мелочи поправили кое-где ошибки синхронизации, и работали с ним без особых проблем несколько лет. Через несколько лет захотели перейти на версию фреймворка посвежее, и оказалось что XPConnect в новой Mozilla стал не thread-safe, видимо не нужно это стало в браузерах... Сейчас там проверка что запускаемся из main thread И всё, сидим на старой версии, сами её портируем на всякие новые (для той версии) платформы например. Иногда удаётся перенести что-то из новой версии (т.е. backport чаще просто напильником...
(1) многопоточное серверное приложение,
(2) клиентское приложение (GUI) для управления.
Я бы переписал Linux-специфичные моменты серверного приложения на кроссплатформенных серверных библиотеках (не QT а GUI - на QT, раз он так нравится.
По серверной части - видимо это pthreads и работа с сетью, так? С pthreads всё просто: берётся библиотека, являющаяся на UNIX/Linux wrapper над pthreads, а на Win32 - wrapper над WinAPI. Таких библиотек сейчас по-моему хватает на любой вкус. Не зная деталей того, как вы работаете с сетью, и какие у вас требования, посоветовать что-то конкретное вряд ли возможно.
Почему не переписать и сервер на QT? Я бы не стал рисковать, переписывая многопоточный сервер на тулките, изначально совершенно не серверном, а клиентском. Потому что есть риск что через некоторое время так сложится, что клиентскому фреймворку (которым является QT) будут малоактуальны ваши серверные проблемы и задачи, и у вас будет выбор: или оставаться на древней версии фреймворка, или существенно дорабатывать новую версию фреймворка (причём, далеко не факт что ваши изменения будут приняты обратно в проект).
У нас так получилось с Mozilla: взяли её из-за NSPR, XPCOM core, движка JavaScript и обвязки XPConnect, прозрачно транслирующей все XPCOM-интерфейсы в JavaScript (т.е. не нужно руками делать JavaScript bindings для каждого нового интерфейса и класса написанного на C++). По мелочи поправили кое-где ошибки синхронизации, и работали с ним без особых проблем несколько лет. Через несколько лет захотели перейти на версию фреймворка посвежее, и оказалось что XPConnect в новой Mozilla стал не thread-safe, видимо не нужно это стало в браузерах... Сейчас там проверка что запускаемся из main thread
И всё, сидим на старой версии, сами её портируем на всякие новые (для той версии) платформы например. Иногда удаётся перенести что-то из новой версии (т.е. backport чаще просто напильником...
Насколько я понял, приложение состоит как минимум из 2 частей:
(1) многопоточное серверное приложение,
(2) клиентское приложение (GUI) для управления.
...
По серверной части - видимо это pthreads и работа с сетью, так?
да, все верно.
спасибо за ответ, похоже, это разумнее всего.
заодно посмотрю что такое "pthreads-win32" ^_^
посмотрю.. но пока QT кажется более интересной.
Оставить комментарий
Vadim69
есть некое приложение, написанное(мной) под линукс на C.приложение использует потоки для всякого(ждем, пишем, читаем, считаем) и активно работает с сетью, общаясь с внешними миром(в том числе с управляющей гуевиной, написанной под GTK и уже не мной) посредством механизмов межпроцессного согласования.
ВНЕЗАПНО появилась необходимость портировать(upd: мм, неправильно немного. не портировать, а "сделать так, что работало и развивалось и там, и там") все это безобразие на венду.
в связи с этим вопросы;
1. правильно ли я понимаю, что самое правильное - переписать все это на плюсах под QT?
2. насколько крив qthread и крив ли вообще? то есть не будет ли быстрее, если сетевую и счетную часть реализовать в виде библиотек отдельно для линукса(она. можно сказать, уже есть) и отдельно для венды(а вот этого не хотелось бы - вникать в WinAPI не хочется)?, а если будет, то насколько?