Замена qt чем нибудь на c.

К сожалению, разработчики GTK игнорируют особенности винды, из-за чего в потоке нельзя просто так взять и получить/изменить что-то в виджетах.

из потока вызвать g_idle_add, и из callback уже работать с виджетом. это официальный способ.

Допустим, понадобится ТСу запустить несколько параллельных потоков + с openMP распараллелить цикл какой… Что-то сомневаюсь, что в мастдае есть pthreads и openMP.

Несвежий OpenMP 2.0 поддерживается компилятором VS (собирать с /openmp, можно включить в свойствах проекта), а в MinGW всё так же, как и в GCC. И pthreads есть в том числе.

Ну, раз так оно все хорошо, то почему уже 2 страницы понавыдумывали?

Зачем?

Удобная платформа, покрывающая практически все наши потребности

Кути удобные? Да ну нафиг!

а на андроиде используете? с размером apk проблем не возникает? гуй адаптировать не приходится с десктопа?

Разве я чтото говорил об андроиде или адаптации чего-либо с десктопа? Нет, не используем.

Толсто

а в MinGW всё так же, как и в GCC. И pthreads есть в том числе.

не путай mingw и cygwin

Разве я чтото говорил об андроиде или адаптации чего-либо с десктопа? Нет, не используем.

тогда и вопросов нет.

Ну, раз так оно все хорошо, то почему уже 2 страницы понавыдумывали?

Лор же. Да и про платформозависимую функциональность и велосипеды на велосипеде это ты себе взял как утверждение.
С потоками-то как раз всё хорошо, но вот с реализацией, к примеру, IPC-механизмов в разных системах на деле могут быть проблемы, даже если на словах поддержка заявлена.
Как пример, можно посмотреть ситуацию с POSIX-совместимой реализацией shared-memory и аналогичной фичей в венде.
Но IPC (и прочие системозависимые вещи) в тулкитах типа Qt отсутствуют по понятным причинам. А всё то, что есть в Qt - великолепно портируется.
Ведь ЕМНИП, ТС искал замену Qt?

Но IPC (и прочие системозависимые вещи) в тулкитах типа Qt отсутствуют по понятным причинам.

http://qt-project.org/doc/qt-4.8/qsharedmemory.html

Кстати да, немного неточно сказал. MinGW не поддерживает pthreads-win32, но вполне с ним работоспособен и идёт в куче сборок (CodeBlocks MinGW, кутешный, сборка того же nixman'a).

Кстати, о птичках. Я как-то с программисткой под мастдайку говорил, мол, почему у нее не используется общение через разделяемую память, а какие-то жуткие велосипеды — она сказала, что в мастдайке вообще такого нет. Неужели? Ну и решето…

http://qt-project.org/doc/qt-4.8/qsharedmemory.html

Вот как знал, что зря не полез в документацию :)
Но всё-таки, толку с такой «кроссплатформенности» немного - стоит посмотреть хотя бы на количество платформозависимых оговорок в описании. В Boost.Interprocess ситуация такая же

она сказала, что в мастдайке вообще такого нет

ламерша

Ну и решето…

дурак

Кути удобные? Да ну нафиг!

Да уж поудобнее всего остального.

Она-то есть, но по сути, это общение процессов через файл подкачки, и есть одно очень нехорошее отличие от POSIX-систем во времени жизни участка разделяемой памяти: в венде вынесет область разделяемой памяти когда завершится последний процесс, использовавший эту память. Конечно, если хочется использовать один и тот же участок до его анлинка/перезагрузки системы, то вендовая реализация не подходит.

Но IPC (и прочие системозависимые вещи) в тулкитах типа Qt отсутствуют по понятным причинам.

4.2

http://qt-project.org/doc/qt-4.8/qsharedmemory.html

http://qt-project.org/doc/qt-4.8/qlocalsocket.html

Она-то есть, но по сути, это общение процессов через файл подкачки

по сути как раз через память, обращение к диску будет только при недостатке памяти

Обход проблемы есть, но он не нужен под линуксом.

из потока вызвать g_idle_add, и из callback уже работать с виджетом. это официальный способ.

Так я ж и написал, что есть такой обход! Им и пользуюсь. И подчеркну: для кроссплатформенного тулкита это обход проблемы (workaround). Т.е. способ хоть и официальный, но это не официальное решение проблемы, а официальный обход проблемы.

Да и честно сказать, я и не помню такого, чтобы где-то была заявлена корректная обработка изменений в UI, сделанных из другого потока.

Конечно, нужно исключить настоящую параллельность для такой операции, что и осуществляется gdk-мьютексом:

void* working_thread(void *arg)
{
    for (...) {
        // ...
        a = calculate();
        gdk_threads_enter();
        gtk_...show (a);
        gdk_threads_leave();
        // ...
    }
}

что за игры в слова? gtk официально не thread-safe. вызывать функции gtk можно только из потока gtk-main (а под виндой и макосью — только из главного потока, т.е. того в котором WinMain, ...). для этого служит g_idle_add. считать это проблемой, или фичей — дело десятое.

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

По какой это причине оно может подвесить? Это что-ж получается, если пользоваться мьютексами напрямую, тоже может просто взять и вдруг подвесить? Сомневаюсь.

Уж лучше под винду, там и нормальный сисярп, и декларативный WPF: одна ляпота.

Qt for Android это пока что ещё не релиз и не продакшен. Даже сейчас там можно собирать приложение с использованием системных Qt frameworks устанавливаемых через ministro.

Собственно миго так располагала системные библиотеки.

На подавляющем большинстве андроидных девайсов будет обозначать «поставить некуда, место на internal storage кончилось».

Да ты ещё не видел MonoDroid :)

гуй адаптировать не приходится с десктопа?

Можно использовать стандартные виджеты но выглядеть оно будет не по мобильному. Не куда не денешься всё равно нужно адаптировать.

А если поменять архитектуру? Использовать тикль для морды и склейки простеньких чисто сишных кусков?

Продолжим рекламную компанию GLib'а:

Кстати, насчет многопоточности. А считать-то как?

Допустим, понадобится ТСу запустить несколько параллельных
потоков + с openMP распараллелить цикл какой… Что-то сомневаюсь,
что в мастдае есть pthreads и openMP.

http://developer.gnome.org/glib/stable/glib-Threads.html
Threads — portable support for threads, mutexes, locks, conditions and thread private data.

А поддержка openMP от компилятора же вроде зависит (и VC++ вроде умеет), хотя лично не сталкивался, могу ошибаться.

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

Продолжим рекламную компанию GLib'а

Все равно я этим велосипедом пользоваться не собираюсь больше, чем нужно для оформления GTK'шных окошек. Реализация всяких списков в нем — через одно место.

По какой это причине оно может подвесить?
Это что-ж получается, если пользоваться мьютексами напрямую,
тоже может просто взять и вдруг подвесить? Сомневаюсь.

Подтверждаю, может. И в самом неожиданном месте.
Выше приводил пример с включенным режимом помощи инвалидам в Гноме.
Хз как этот режим влияет (какие-то свои (кривые?) коллбеки добавляет на вывод-ввод Gtk или что), но висло. Пришлось переделывать.
Так что только gui в один поток, только хардкор.

По какой это причине оно может подвесить?

вот пример

поток 1:

lock_my_mutex // my_mutex — некий global lock для собственного кода lock_mutex_gtk .... unlock_mutex_gtk unlock_my_mutex

поток2 (gtk_main):

lock_mutex_gtk (делается автоматом) вызывается обработчик какого-то event // в этом месте будет случайный висюк lock_my_mutex ... unlocl_my_mutex unlock_mutex_gtk

Это что-ж получается, если пользоваться мьютексами напрямую, тоже может просто взять и вдруг подвесить? Сомневаюсь.

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

Qt for Android это пока что ещё не релиз и не продакшен.

я видел демо видео на их сайте. но из него мало что понятно.

Да ты ещё не видел MonoDroid :)

и не горю желанием видеть :))

извиняюсь, забыл про lorcode.

поток 1:

lock_my_mutex // my_mutex -- некий global lock для собственного кода
lock_mutex_gtk
....
unlock_mutex_gtk
unlock_my_mutex

поток2 (gtk_main):

lock_mutex_gtk (делается автоматом)
вызывается обработчик какого-то event
// в этом месте будет случайный висюк
lock_my_mutex
...
unlocl_my_mutex
unlock_mutex_gtk

Там было гораздо хуже, чем ССЗБ :)

К сожалению, разработчики GTK игнорируют особенности винды

И правильно делают.

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

По-моему в то время появился .NET. Он точно был в начале 2003 года в версии 1.0, и я даже на C# писал тогда.

К сожалению, разработчики GTK игнорируют особенности винды, из-за чего в потоке нельзя просто так взять и получить/изменить что-то в виджетах.

Под Linux'ом лучше тоже этого не делать...

Дык, далеко не все методы можно просто так дёргать из произвольного потока без синхронизации с крутилкой оконных сообщений. В Qt на такой случай есть QMetaObject::invokeMethod, в C# тоже что-то похожее. Так что это не «особенности винды», а «особенности графической подсистемы».

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

boost::interprocess. Сразу вспоминается анекдот про женщину-программистку, и морскую свинку.

Так это ж проблема не gdk-мьютексов, а принципиальная проблема организации работы с несколькими мьютексами! Это значит, что если человек умеет работать с несколькими мьютексами, то у него не будет проблем и с gdk-мьютексами, и наоборот :)

без синхронизации с крутилкой оконных сообщений

Так синхронизируем же gdk_threads_enter()/leave(), но под виндой они чего-то не додумали, и там так низзя. Вон пишут 3.0, 3.2, 3.4,... 4.0, но так и не собираются доделать то, что начали многие годы назад.

В смысле, под виндой эти gdk_threads_enter()/leave() криво реализованы?