Russian Qt Forum

Показал простейшие проги на Qt одному знакомому прогеру, и тот долго удивлялся, почему прога, состоящая из окна и кноки, его закрывающего, кушает в оперативке 9 метров, а диалог find (из книги Бланшет) - 11.5 метров?

Где-то теряется этап оптимизации?

Навпаки. Оптимізація на вищому рівні. Завдяки цим 9 Мб все працює дуже швидко. Сокети, внутрішні буфери, таблиця юнікодів, кодеки, плагіни, що автоматично підвантажилися, подвійна буферізація та ще безліч речей, про які ніби усі й забули. Як раз за рахунок цієї пам'яті архітектура програми на Qt екстремально проста.

Все равно странно...
Но спасибо и на этом...

Просто тот прогер пишет на чистом WinAPI и утверждает, что все остальное  -отстой, в частности потому что память кушает...
ИМХО, он не прав.

Знаю я таких "прогеров", зачастую один понт только, а в нормальных, более менее крупных проектах, толку от них никаккого. У меня есть знакомец, так он из принципа до сих пор под винды на ASM-е пишет, и что? Та прога которую он месяц рожает пишется за 15 минут. Кому нафиг нужна такая производительность. Переносимость не то что между разными ОС нету, она даже между разными процами одной фирмы неочень то переносится. Но это уже совсем крайний случай.  :lol:
Немогу представить себе проект которому было бы жизненно необходимо реализовывать ГУЙ на чистом WinAPI. Для реализации простейшей функциональности кода туева хуча нужна, а чуть что по сложнее нкжно так сидиш и неделями рожаеш какой нибудь задрипаный контрол. Программист должен реализовывать свою конкретную задачу, а не заниматься написанием графических библиотек (если он не сотрудник Trolltech конечно же  :lol: ), именно за это ему деньги платят. Оставте создание подобных библиотек специалистам. Каждый должен заниматься своим делом.
А для функциональности Qt ее размер весьма не велик, надо помнить что она почти весь интерфейс рисует сама и не использует для этого стандартные виндовые контролы.
З.Ы. А еще меня бесят крутые WinAPI программисты которые не разу не в состоянии написать нормальный масштабирующийся диалог. Так как реализовать это на "ЧИСТОМ" API ... проще утопиться. И я как ... должен (на разрешении 1600х1200) в манюююююююсеньком диалоговом окне выбора файлов (где их только 4 штуки и видно) полчаса возякать мышкой что бы найти нужный. Лучше уж ни какого GUI,чем такой.

Ладно, все, перкращаю, а то такого здесь понапишу. Надеюсь основную мысль свою мне удалось донести до читателей сего опуса.

не поймите не правильно, я за QT руками и ногами, но вот 4 метра на виджет с лейблом все-таки многовато. И как-то это не вписывается в главный принцип C++ программиста : не платить за то, что не используешь.

кстати, никто не вкурсе как при простое сократить исрользование памяти, в Qt3 ассистент при свертывании кушает вместо 6-7 метров ~1,5 ?

Насчет памяти я думаю так:
Если расматривать QT по уровням, то:
1. Высокороуровый интерфейс
2. Ядро QT
3. API системы( WinAPI для Windows, Xapi для Linux)

По этому простейшая кнопка так много весит. НО даже 15 мегобайт при современной оперативке это такая фигня.

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

По архитектуре Qt, сильно связанная, древовидная библиотека. Достаточно посмотреть на структуру классов (где то у них на сайте в pdf файле валяется). Вся она растет из одного корня - QObject, и имеет мощный механизм наследования функциональности. Сама кнопка имее ничтожно мало собственного кода, а остальной тянет из своих предков. И естественно никак не может без них обойтись. Это неизбежная плата за Объектно Ориентированную Структуру. Но посмотрите, ведь чем крупнее становится проект тем этот недостаток становится все менее ощутимым, а при разрастании кода свыше определенного предела и вовсе становится преимуществом, так как тупой механизм plain api будет требовать немерянных сил для поддержания целостности проекта и постоянного увеличения кода для реализации новой функциональности. А при использовании грамотно построенной Объектно Ориентированной библиотеки, все эти проблемы будуту разрешаться сами собой без каких либо усилсий со стороны программистов.
В четвертой версии программисты trolltech довольно грамотно разделили свою библиотеку на взаимно не зависимые модули и тем самы предоставили возможность облегчить пользовательское ПО от не нужной функциональноси. Самая толстая из библиотек QtGui весит около 3.5 Мб. Для написания софта без графинтерфейса можно обойтись и того меньшим. Понадобится только QtCore, весом около 1 Мб. А чего стоит класс QThread в новой библиотеке, это же просто сказка какая-то. Наличие цикла обработки сообщений и потокобезопасных сигнал-слотов, делают его (поток) по функциональности не уступающим настоящему приложению только выполняющемуся в рамках вашего процесса.
Надеюсь мои мысли ясны, и вопросов про размер приложения с одной кнопкой более не возникнет. Так как это черезвычайно глупый и не состоятельный пример.
 

Хотелось бы сказать, что я не являюсь сторонником лозунга : "Памяти у нас до .... , а если вам мало то купите еще она ведь дешевая". Так как софт пишется не только для персоналок, где этот лозунг может и имеет право на существование (в чем я лично сомневаюсь), но и для встраиваемых решений, а тут с этим ресурсом ой как туго бывает. Но свой рразмер Qt оправдывает функциональностью на все 100%, тем более что есть Qt Embedded.
Все, я кончил.  :D

З.Ы. Как нибудь поинтересуйтесь сколько весит Последний MFC и чего он умеет по сравнению с Qt. Будите приятно удивлены.  :wink:

А че там с MFC? для  меня VC6 закончился на 6 версии!

Да ничего вобщем-то.  :D  Размер статической библиотеки около 2.5 Мб. Я имел ввиду все это относительно функционала, а так же нестоит забывать что MFC не имеет собственных контролов, а лишь обертки для уже имеющихся в системе. Так что сами считайте.  8)

ИМХО, это всё-таки лучше, нежели запустить жаба-машину.

добавлено спустя 1 час 12 минут:

 
Скажи ему, что сейчас под винду надо разруливать на ATL/WTL ;)