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

>>У них отлично получается вносить этот новый функционал:) Кеды вон постоянно переписывают,как только очередной релиз выйдет

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

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

3) Для Qt нет моно, и это есть хорошо )))

zypper info qtsharp
Загрузка данных о репозиториях...
Чтение установленных пакетов...


Сведения — пакет qtsharp:

Репозиторий: openSUSE:11.2
Имя: qtsharp
Версия: 0.7.1-238.3
Архитектура: i586
Производитель: openSUSE
Установлен: Нет
Состояние: не установлен
Размер после установки: 7,1 MiB
Сводка: Qt Bindings for C#
Описание:
This package contains Qt C# bindings, which can be used with the Mono
or pnet compiler.

P.S. На всякий случай - Емакс наше всё, вим отстой

сколько проектов на кутях-шарпе написано ? хоть один бы глянуть ради праздного интересу.

o_0 мигель изыди!!!

[kosyak@netbook ~]yaourt -Ss qtsharp

[kosyak@netbook ~]

Если мне не изменяет память - синапс (им-клиент со всякими свистоперделями)

>Gtk и Qt сравнивать уже просто неккоректно.

Gtk - библиотека для отрисовки виджетов на страшной помеси C и C++
Qt - кроссплатформенный фреймворк (гуй, сеть, БД, мултимедиа, XML, D-Bus, и даже (ужоснах) ActiveX) на православном C++

Конечно ересь, но опередил в том что сравнивать их абсолютно некорректно. Предлагаю другое сравнение. Сюда учтем возможности и мощность, надежность и ABI, использование памяти и тд. А еще соответствие стандартам языков, количество байндингов и далее.

Так вот, барабанная дробь и вброс.

{Gtk/friends = Gtk+, Glib, GDK, libgda, Cairo, Pango, Clutter, GNet GObject+introspection, gvfs, ORBit, Gtk-server} vs {Qt4}

Gtk/friends - набор библиотек с большой степенью интегрированости с друг другом. Тоесть использование одной скорее всего располагает при расширении функциональности приложения использование и других их этого набора. UNIX-way. Некоторые зависят от друг друга, так что часто присутствуют вместе. Но вообщем можно создать приложение с минимальными зависимостями, пользуясь только несколькими библиотеками, которые по отдельности не такие монстры как qt. Но зато вместе... Кто-то курит в сторонке.

Qt состоит из нескольких библиотек. Для конкретного приложения можно можно использовать только необходимые бидлиотеки, а не тащить всё.

И еще... Там был флуд по поводу того, что в G* стеке нет доступа к бд. Так вот его предоставляют libgda (только доступ), libgnomedb(еще и виджеты). Скоро будет на Windows. Чуток в этой сфере опоздали за Qt4. Хоть это и гномолиба, перенос на Windows будет. А на Windows ведь нет Gnome. Вот и профит от Unix-way.

Кстати. У себя в универе когда по каким то предметам нужно сдать лабы только на Linux и нужен гуй, а люди обращаются за советом, то я им советую Qt4 и QtCreator. Почему? Я не против Qt и обычно не против никаких хороших и мощных технологий. Просто времени нет, а у Qt низкий порог вхождения. Когда проэкт большой и надо много всего, то конечно советую G* стек. А что бы человек не страдал, то советую юзать binding и миф о ужасах в С именовании gtk функций пропадает. Есть и OOP и сборка мусора.

> Кстати. У себя в универе когда по каким то предметам нужно сдать лабы только на Linux и нужен гуй, а люди обращаются за советом, то я им советую Qt4 и QtCreator.

Интересно, а чем им PyGtk не хватает? >_<

мдя, что-то даже про delicious забыли (

ну мне QT показалось удобнее. Тем более, что можно PyQT использовать - осваивается на удивление быстро.

>В любом случае объектная модель ГОбжекта превосходит стандартную плюсавую

они изобрели ObjC, нет ? писали бы сразу на нем.

У вас сильно крутое мнение о студентах. У нас большинство знают Pascal, C, C++, {C#,Java}. Одно дело быстро посмотреть мануал по Qt4 и накатать небольшую прогу. А другое дело выучить питон на уровне хорошем для написания сложных алгоритмов. Я ведь PyGtk могу предложить только для большого проэкта, когда есть смысл «осиливать». В условиях минимума времени и максимума нагрузки мышкоклацание в QtCreator вполне сойдет

Это меня интересует. Я не знаю почему нет и какие профиты у обоих. Может не хотели ставить в основу платформы что-то другое кроме провереного С. С С ничего не случится, а вот выпиливать ObjC будет сложно если все от него отвернутся. Мое объяснение

ОбжСи семантически ближе к Smalltalk, а это немного не то

Написал, потому что раздражает сравнение Gtk vs Qt, OpenGL vs DirectX и другие сравнения, где одно специализировано на одну задачу и хорошо интегрируется с другими продуктами, которые ориентированы на свои задачи, а другое - комбайн «все в одном»

Во friends еще надо долить GStreamer и gtkglext

> P.S. А в GTK видимо и нет аналога QProcess

В Gtk нет. Но Glib кагбы намекает http://library.gnome.org/devel/glib/unstable/glib-Spawning-Processes.html

>> MuZHiK-2

Ну-у-у-у, чуваак, твой-то диагноз всему ЛОРу известен: моногном головного, спинного и костного моска. Твой ник уже имя нарицательное )))

Тут говорить нечего - ты даже хелловорда не написал на гтк. Сплошное 4.2.

Хелловорлд написал. Поблевал на клавиатуру, и ушел писать на Qt.

Особенно там сверхкачественный секс при работе с базами данных на разных платформах.

Пруфлинк? Или концентрированный метан?

Теперь по сабжу: лучше не использовать кутешные контейнеры кроме QList (и то в случае крайней необходимости) и QString вообще

Пруфлинк? Или опять метан? У меня довольно немаленькая программа, повсеместно использующая все возможные кутэшные контейнеры, QtScript, динамическую подгрузку UI с сервера приложений, WebKit, после двух часов отладки системы работы с документами кушает 200 метров памяти. (файрфокс с 5 вкладками - 280, ГТКшная PHP-IDE с 6 вкладками - 280)

идеалом был бы ObjC с синтаксисом С++

ааа. видимо я просто неправильно понял:) инверсно

нет. зачем?

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

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

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

Авторитетное и, самое главное, аргументированное мнение, да.... =\

кстати я немного в анабиозе - для сиплюсплюс (считая куте) есть ORM? Или так и придется согласовывать свою модель с тем интерфейсом, который предоставляет тот же куте?

P.S. я только интересуюсь:)

>Ну а так куте отстой потому что мок, тормоза от метаобъектов, шг и банальная изоляция.

Вот скажи мне, какая тебе нафиг разница, чем добавлен некоторый синтаксический сахар: моком или макросами? На выходе всё равно обычный код.

Тормоза от метаобъектов? Бенчмарки в студию.

Про «шг» умолчим, этот спор нескончаем, и мне недавно один маковод с пеной у рта доказывал, что та мазня, которую он имеет у себя - идеал.

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

>Кто-то курит в сторонке.

И я даже знаю, кто. Ибо Qt4 - ни разу не монолит, как себе его представляют некоторые не владеющие предметом разговора, а набор модулей QtCore, QtGui, QtMultimedia, QtNetwork, QtOpenGL, QtOpenVG, QtScript, QtScriptTools, QtSql, QtSvg, QtWebKit, QtXml, QtXmlPatterns, Phonon.

>кстати я немного в анабиозе - для сиплюсплюс (считая куте) есть ORM? Или так и придется согласовывать свою модель с тем интерфейсом, который предоставляет тот же куте?

Не знаю, как в «остальном сиплюсплюсе», но в Qt нет, и не планируется даже в 4.7. Вопрос задавали тут http://blog.qt.nokia.com/2009/10/21/qt-4-7-is-in-the-works/#comments , ответ там же.

Плюсую! :) какашки в сторону Qt не обоснованны...

1. Если честно, мне как разработчику разницы абсолютно никакой, как оно там работает изнутри. Куте - хороший фреймворк, который удобно и эффективно можно использовать для построения сложных приложений. То, что такой продукт существует,меня только радует. Я просто развлекаюсь в конце рабочего дня - авось что нибудь новое узнаю для себя :)

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

(одним сообщением телефон не осилил)

...про потребляемую метаобъектами память тут уже обсуждалось ранее, в подобном же треде. Но компиляция хеловорлда на гтк всё равно быстрее чем аналога на куте

3. У маководов особые яблочные мониторы

4. Под изоляцией имелось не интеграция в пользовательскон интерфейсе :) а взаимодействие с самой системой. Куте в большей степени загоняет программиста в рамки фреймворка, впрочем, на то он и фреймворк

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

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

ну давай, скажи нам за память)

>Но компиляция хеловорлда на гтк всё равно быстрее чем аналога на куте

Очень нужно пользователю преимущество.

|нужно ➞ нужное|

Qt написано на С++, плюс ещё этот moc - в результате биндинги к другим, нормальным языкам писать сложнее, поэтому их и меньше. Вот, пожалуйста

Отрыл еспешшали фор йю

http://www.linux.org.ru/jump-message.jsp?msgid=3845659&cid=3847943

Енжой бейба

>Но компиляция хеловорлда на гтк всё равно быстрее чем аналога на куте

Компиляция С-кода в общем случае при прочих равных всегда быстрее компиляции С++-кода.

Куте в большей степени загоняет программиста в рамки фреймворка, впрочем, на то он и фреймворк

Мне никто не помешал в своё время юзать STL и некоторые сишные либы в проекте, а в данный момент, например, в рабочем проекте используется Glib и evolution-data-server.

Проблема надумана, никто никого никуда не загоняет. То, что отпадает _необходимость_ в некоторых вещах - да, но _возможность_ использовать эти вещи - не отпадает.

Не знал, что мужЫк-2 заводится на Qt vs gtk. Это баг или фича?

>> Не знал, что мужЫк-2 заводится на Qt vs gtk. Это баг или фича?

Он заводится на всё, что (!gtk && !(mono || .net) && !gnome && !windows). Так что это - не бага, а фича, именно на это его программировали создатели

>>Куте в большей степени загоняет программиста в рамки фреймворка, впрочем, на то он и фреймворк

Мне никто не помешал в своё время юзать STL и некоторые сишные либы в проекте, а в данный момент, например, в рабочем проекте используется Glib и evolution-data-server.

То моё предыдущее приложение специально не процитировали? =)

---> взаимодействие с самой системой <--- это всякие Windows-Unix-итд-специфичные вещи. По моим субъективным ощущениям, при работе с ГТК в этом плане свободы гораздо больше

>> взаимодействие с самой системой <--- это всякие Windows-Unix-итд-специфичные вещи. По моим субъективным ощущениям, при работе с ГТК в этом плане свободы гораздо больше

Зато - очень высокая кроссплатформенность. Для ОС-специфичных задач логичнее брать ОС-специфичный тулкит, верно? ИМХО - бред брать кроссплатформенный тулкит для реализации расово неверного и еретического^W^W^W^WCOM/activex-компонента, или, например, вируса. Зато, например, для графики/мультимедия, или текстового процессора, системы управления документооборотом или бухгалтерской программы, почтового или торрент-клиента, IM-клиента, SaaS-клиента накрайняк - логичнее и правильнее взять максимально кроссплатформенный и безгемморойный тулкит.

>{Gtk/friends = Gtk+, Glib, GDK, libgda, Cairo, Pango, Clutter, GNet GObject+introspection, gvfs, ORBit, Gtk-server} vs {Qt4}

Расслабьяся уже:)) Не сравнивай целостное решение и кучу либ. Тем более даже с кучей либ гтк по функционалу не догонит Qt.

4.2

а теперь признайся сколько кроссплатформенных проектов ты сделал на qt ?

Да, ты перданул так перданул.

А теперь попробуй из этой солянки слепить действительно кроссплатформенное приложение.

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

> И я даже знаю, кто.

Вы серьезно думаете что в qt4 есть вся функциональность, которая присутствует в том списочке???? Так я его еще не закончил. Одинаковому стилю именования и документации соответствеют еще много библиотек, которые рекомендуются к использованию с гномовским стеком. xml? libxml2 - и т.д. После гномолиб я ничуть не удивился тому как там все устроено. Если еще приблизится к гному, то горизонте маячит gconf. Сдесь вообще кто-то скурился до смерти.

Qt4 - ни разу не монолит

Конечно же вы правы. И зависимости тоже отдельные, не на весь qt4, а на модули. Часто хватает только QtCore и QtGui. Мое возмущение вызвала привычка сравнивать горячее с велосипедом. Вам провести аналогию? Ок. Представьте что все тролли на форумах заладили сравнивать QtGui vs Java SE 6, и заметьте, не QtGui vs Swing как должно быть. Я думаю это вызвало бы возмущение. В таких глупых ветках форума и рождаются глупы вопросы типа «А в вашем Gtk нет аналога QProcess?». Тогда «На вашем QtXml не работает видео, а вот GStreamer - прекрасно работает любое, причем с фильтрами эффектами и pipeline архитектурой»

> А теперь попробуй из этой солянки слепить действительно кроссплатформенное приложение.

Никаких проблем не вижу. И кто боится С, для того есть байндинги, которые снимают все проблемы. Qt4 делали для С++, G-stack делали для всех возможных байндингов.

Вы просто подменяете понятияю. Сказать что Qt - проще? Нет. Мощнее? Ну чем тот список, в разы слабее. Он более, как бы сказать... Straightforward. За счет этого и достигается RAD и эффективность. У него очень низкий порог вхождения. За счет того что все делается очевидно, а не как то хитро чтобы достигнуть гибкости и продуктивности в будущем. Кто бы подумал что гора либ будет более легко разделима на отдельные команды разработчиков, которые сделают очень мощные специализированый либы и их страдания на С выльются в легкую генерацию bindings и четкий ABI, и в итоге в более функциональный продукт. Но это продумали заранее и так и получилось.

Это мужик-2 подзагнул... Может просто не разбирал Qt чтобы трезво оценить. Вот *process и сбил с толку. Хотя процесс - это не поток... whatever

>> Если еще приблизится к гному, то горизонте маячит gconf.

Это - это грязное подобие вендореестра, хрень для свалки мусора без возможности хоть как-то там что-то разобрать? Да-а, тут действительно не то что скуриться, спиться до смерти можно =))

И зависимости тоже отдельные, не на весь qt4, а на модули. Часто хватает только QtCore и QtGui. Мое возмущение вызвала привычка сравнивать горячее с велосипедом. Представьте что все тролли на форумах заладили сравнивать QtGui vs Java SE 6

В холиварах Qt vs Gtk, как правило, сравнивают удобство разработки на этих тулкитах, их прожорливость, удобство интерфейсной части, кроссплатформенность, да кучу всего ещё. При разработке под Qt не нужно иметь геммороя с кучей разнородных либ gtk + ..., ..., ..., ..., ..., ..., их версиями, совместимостью, совместимостью разных версий под разные платформы и т.д. Есть фреймворк, и он покрывает 80% потребностей разработчика.

GUI (интерфейсная) часть Gnome/GTK тоже, мягко говоря, не на высоте. Похоже, что HIG - это нечто вроде болезни: На всякую ересь, типа выпиливания иконок, внимания обращают много, а на вопиющие недоработки, в виде полупустых и развёрнутых на весь экран комбобоксов, абсолютно неюзабельных файловых диалогов, гигантских по умолчанию кнопок - почему-то положили с большим прибором, и твердят что «так надо».

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