Программирование с Qt : Часть 3. Контейнеры

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

>>По одной этой фразе можно сделать вывод какой из тебя «программист». За яйца надо подвешивать на использование потоков не по назначению.

Я привел конкретный пример использования потока? Нет, так что ты как-то перданул слишком громко. Да, кутешный QThread - это обвертка на pthread, так зачем мне эти фантики, если я могу напрямую pthread использовать? Велосипедисты-кондитеры, блин.

> Результаты:

А как профайлер? Или вы time'ом ))) Время в ядре на синхронизацию или хз-что засчитан. Не наезд на фаш фетиш, но просто хотелось бы узнать почему одно быстрее, другое медленее. Ведь обы кода сильно вылизаны специалистами. И хорошо спроэктированы. Я думаю вы не верите что у Qt просто хорошая аура. Наверно есть разница в функциональности или что?

Ну вот твой тест и доказал, что STL и то быстрее кутевых контейнеров. А по-поводу того, что bytearray оказался быстрее на 3 секунды стрингов, скорее всего это из-за использования ссылок на одинаковые строки.

> Да, кутешный QThread - это обвертка на pthread

Там был QProcess. Запуск приложений с пайпами на вход и выход. Есть точный аналог в GLib. В GLib дают дескрипторы, а в Qt в классе есть спецфункции. Конечно не торт если надо пускать дальше по конвееру. Зато у них удобно встроены уведомления о том, что можно читать вывод, сигналами. В Glib нужно использовать другие функции для слежения за дескриптором. Хотя я бы просто в потоке запустил синхронное чтение.

Вот pthreads - не торт, я бы рекомендовал кроссплатформенный вариант. Производительнотсь ведь не теряем. Или из GLib, или из QtCore. Нужно оценивать приложение

> *ваш, а не фаш. Как на лоре изменять посты???

Кстати. А как насчет boost? тот код на нем как работает?

прежде чем пердет тут, осиль для начала чем QProcess от QThread отличается.

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

«не верю» (c)

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

>Java

<троллмод>Тормоз:))</троллмод>

Ты будешь сравнивать Swing с QtGui? Не смешно.

А в остальном да, ява.

>а теперь мистер лгун, расскажите когда последний раз менялось API Unix?

Что такое API Unix?

>> Когда меня будет знать полмира - будешь еще автограф просить.

Так и запишем: мания величья, gnome, острая параноя. Назначаю цианид, 5 мг, принимать утром и вечером до полного выздоровления.

З.Ы. Передавай превед Наполеону!!11

Конечно, для быдлокода кутя самое то, пишется быстро и не думая.

Не путать Qt с моно.

Возьми, например, постгрес. Напиши в линаксе простейшее приложение и потом собери его в винде и заставь работать. Секс будет. Качественный.

Полтора года назад с Ораклом работало. Из под маздая и из под линукса. Без геммороя. Потом перешли на трёхзвенку, щас драйвер СУБД вообще не нужен. Со слоником не пробовал, надо будет потестить, самому интересно...

Если ты заглянешь внутрь контейнеров, то увидишь, какие там накладные расходы. Нет, если у тебя с контейнерами пару объектов - все еще более менее нормально, но как только число используемых контейнеров растет, кутя начинает сливать.

В моём рабочем ппроекте используется сотни контейнеров разных типов (один экземпляр xmlDataModel создаёт и постоянно использует пять контейнеров). И ничего, память не утекает, тормозов не замечено, полёт отличный. Так что не бздеть.

>на одном военном предприятии стартнули проекты в куте3 и гтк2. через год куте3 уже сдох, за перенос в куте4 заказчик бабло выделять не будет.

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

Еслиб ты хоть краем глаза глягул на Qt, то зналбы что портировать с 3 на 4 проще простого. Так что нефиг сказки рассказывать.

и libpcre и libxml и libgl и libcurl и libjpeg

И какое отношение эти либы имеют к гтк? правильно, никакого.

>Да, кутешный QThread - это обвертка на pthread, так зачем мне эти фантики, если я могу напрямую pthread использовать?

Зачем тебе Си, если ты можешь писать на ассемлере?

> хотелось бы узнать почему одно быстрее, другое медленее. Ведь обы кода сильно вылизаны специалистами.

Код Qt не всегда так уж и вылизан. Одних баг я им напостил уже больше десятка. И разумеется, внимания sgi/gnu-той реализации stl было уделено больше, чем контейнерам в Qt, которые и появились-то не так давно.

Потенциальная возможность тормозов — из-за того, что в QMap объединен функционал map и multimap. Но скорее всего, stl просто или лучше вылизан по микрооптимизациям, или хитрее ведет себя алгоритмически.

Главное преимущество Qt-шных контейнеров - это COW (там, где оно есть). А также встроенный в Qt механизм сериализации, который может с ними нативно работать.

Однако я не берусь говорить ничего про производительность QList, QVector, QSet, QHashMap и других, которых я не тестировал. Это к мужику-2, который ничего не тестирует, зато кроет всё сплеча.

>Что такое API Unix?

уже написали, что API доступный по заголовкам из /usr/include/*.h и /usr/include/sys/*.h

>Зачем тебе Си, если ты можешь писать на ассемлере?

Что мешает писать на С++ и использовать pthreads?! Этот вопрос выше попытка свести суть до абсурда.

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

троллтехи начали писать Qt, если не ошибаюсь, тогда когда ещё шаблонов в стандарте не было...

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

под виндой GTK нормально смотрится http://blog.brothersoft.com/wp-content/uploads/2009/04/windows_7_testing_gimp...

>Что мешает писать на С++ и использовать pthreads?!

Если я пишу на чистом с++ то так и есть. Но если я пишу на Qt, то нафига мне эти грабли?

Всё равно, что спросить - что мешает писать на С++ и использовать char[] вместо std::string?

>под виндой GTK нормально смотрится

А теперь этот же скриншот, только с диалогом открытия файлов :))

> Т.е. после 2-3 лет развития библиотеки уже просто _нереально_ взять и поменять неудачные решения.

Именно из-за этого библиотека глобально переделывалась ТРИ раза: Qt1->Qt2->Qt3->Qt4. И именно поэтому в qt4 большинство решений уже крайне удачны.

>Если я пишу на чистом с++ то так и есть. Но если я пишу на Qt, то нафига мне эти грабли?

Всё равно, что спросить - что мешает писать на С++ и использовать char[] вместо std::string?

Исходя из этих предложений (противопоставления С++ и Си, С++ и Qt) следует логический вывод, что по твоему есть чистый С++ и есть Qt (видимо обрезанный С++ и классы Qt).

Вообще, возможность работы с контейнерами Qt в стиле Java есть ересь и отступление от принципов С++.

Ты менюшки и диалоги покажи. А еще gimp сам по себе неюзабельное убожество без MDI.

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

MDI ведь уже давно признан неудачным решением, или опять всё переиграли?

// C.: error Mr

Запустил гимп под виндой. окно выбора файлов как в гноме а не винде, но не сказал бы что это минус, по моему даже удобнее. А окно печати вообще почти одинаково, только в него добавлены еще те настройки которые в винде зачем то вынесены отдельно, в «параметры страницы».

>> MDI ведь уже давно признан неудачным решением, или опять всё переиграли?

Тогда почему фотожаба успешно его использует, и работать с фотожабой удобно, в отличие от гимпа с его абсолютно неюзабельным многооконным интерфейсом. Кстати, в Qt MDI есть. А вот в гтк его никогда не было...

подскажите, для ubuntu karmic бинарники qt 4.6 и qt creator 1.3 где можно скачать?

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

А вот в винде MDI юзался повсеместно. И то, что в Qt есть MDI, как бы намекает =)

И вообще это хорошо, это просто замечательно что в GTK нет MDI. Управлять окнами должен оконный менеджер, а не фреймворк, на котором написано приложение.

Как мне сделать чтобы все окна gimp'а всегда возникали в одних и тех же местах? Как мне сделать одновременный ресайз всех окон гимпа, перемещение и перенос их на другой монитор? Может быть хитрожопыми скриптами это решается, но задачу получается уже делает не менеджер окон, а пользователь.

>Да, кутешный QThread - это обвертка на pthread, так зачем мне эти фантики, если я могу напрямую pthread использовать? Велосипедисты-кондитеры, блин.

А когда понадобится переносить это счастие на Винду, ты напрямую заюзаешь виндовые средства, да? Молодец. И разумеется, как хороший программист, обернёшь всё это безобразие так, чтобы наружу не торчали платформо-специфичные куски, правда же? И получишь.... (тада!)... тот же QThread, но под другим именем. Велосипедисты, говоришь? %)

см. ответ на моей аватарке =)

всегда возникали в одних и тех же местах?

Увы, в FVWM нет матчилки по ролям окон, но при появлении джимпового окна на экране его можно роль можно получить в скрипте из xprop, в этом же скрипте кейснуть что это за окно и сказать FVWMу, куда его разместить

Как мне сделать одновременный ресайз всех окон гимпа, перемещение и перенос их на другой монитор

В одну строчку

 All (gimp) ... 

Где вместо многоточия - конкретная команда (ресайз, перемещение, перенос - всё есть) или более сложная самописная функция.

В итоге пользователь один раз говорит оконному менеджеру, что как и куда, а тот уже каждый раз будет делать как сказано - идилия :)

>А когда понадобится переносить это счастие на Винду, ты напрямую заюзаешь виндовые средства, да?

а когда из винды успели вырезать поддержку POSIX?

Какие еще команды? Я хочу мышкой все делать. А если gimp-образных приложений десяток? Это ж целый геморрой. Чуть нестандартная ситуация и опять лезть править конфиги. Ужас.

команды в конфиге, которые можно забиндить на клавиатурные сокращения, пункты меню и даже жесты мышкой

there is no silver bullet ^_^

>> У фотошопа ноги растут из страны яблок, а там я что то не припомню чтобы MDI использовался.

Эм-м-м-м... http://www.qweas.com/downloads/graphic/editors/scr-adobe-photoshop-cs4-for-ma...

Моя глаза мне нагло врёт, или это таки MDI?

И то, что в Qt есть MDI, как бы намекает =)

А ещё в Qt есть кнопки и менюшки! О ужос! Они же используются в венде!!11 Вотакэээ, выпилим кнопки и менюшки, заодно с MDI!!!

А вообще - хорошо, что есть MDI, пусть лучше будет, чем его не будет. А то гимпообразный ужос плохо влияет на мою нервную систему. Жду однооконного режима ГИМПа (а также - 16 бит), чтобы таки начать его юзать.

в данном конкретном вопросе MDI как раз и есть silver bullet

> И какое отношение эти либы имеют к гтк? правильно, никакого.

Имеют весьма косвенное. Обьясню. Просто использование специализированых либ дает более широкую функциональность. libcurl читал? Я пишу программу с libxml2 и gnutls. Идея не возникает их на что то менять. Они были сделаны специально для того чтобы решить поставленную задачу наиболее эффективно. Только важно следить за переносимостью. Опять же, pthreads - спец либа. Но она не переносима на винду (поправьте если можно перенести без cygwin)

бла-бла-бла ... MDI ... бла-бла-бла

Любая фича есть профит. Я вопросом не интересовался по МДИ и насколько мне былой опыт подсказывает в поиске фич - в g-stack есть почти все что может придумать здоровая и иногда даже больная фантазия. Думаю что мди вопрос както решается. В гимпе не используется, ибо пахнет МС и 90-тыми. А если не решается, то это конечно плохо, ибо я за наличие любой фичи без исключений. Ничего не закапываем.

>> бла-бла-бла ... MDI ... бла-бла-бла

Решение проблемы MDI на современный лад - ВКЛАДКИ!!!! Кстати - таки да, очень удобно было бы в ГИМП иметь интерфейс с вкладками.

На какой там стадии GimpShop? На википедии по оригинальному GIMP в статье о MDI написано что оно есть через плагин. Вообще MDI не очень X дружелюбно. Велосипедить управление окон... А если не поддерживается, то и декорировать вручную? Наверное и такое бывает. Но опять же, фича - это плюс. Пусть потом разрабы решают что им использовать.

А вкладки действительно очень удобное решение

>> Вообще MDI не очень X дружелюбно.

А если не поддерживается, то и декорировать вручную?

Qt Designer с MDI - оч-чень удобно...

> под виндой GTK нормально смотрится http://blog.brothersoft.com/wp-content/uploads/2009/04/windows_7_testing_gimp...

Я под ХР ставлю Clearlooks на гтк. В итоге красивее винды. А на висте и 7 пусть лучше стандартная Windows Impersonator тема. Тогда он в точности клонирует Windows Vista/7. Нормально смотрится. Хотя и тут Clearlooks тоже ничего

CS4 - еретическая версия.

Вот - http://www.algorithm.com.au/albums/screenshots/Phear_MacOS_X.sized.png то что надо

>> Вот - http://www.algorithm.com.au/albums/screenshots/Phear_MacOS_X.sized.png то что надо

Это какой-то фарш.

Windows Vista/7

не нужны. Т.к. нет ещё в мире оборудования, на котором оно не тормозит.

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

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

А вообще ставим Gtk Theme Selector. И качаем темы отсюда http://gtk-win.sourceforge.net/home/index.php/Downloads. 20% тем - реально тру. Clearlooks, Nimbus, Human, их вариации и еще. Тем более что это движки. А можно ведь и gtkrc подредактировать. Сча поставил нимбус, почти как Java или по дефолту на OpenSolaris проги выглядят. И это в винде