qt

[metaclass]

Наконец, вместо того, чтобы копировать qt с компа на комп и копаться в его исходниках, немного побаловался с написанием программ. Выводы:
1) qt creator (и возможно, сам qt) еще таки дорабатывать и дорабатывать. Глючит-с. Мне кажется, что это не уровень RC, это таки сырая бета.
2) qt не использует стандартных виндовских контролов вообще, судя по тому, что spyxx не видит ничего в проге кроме топ-левел окна.
3) Способ разработки гуя достаточно интересен, некоторые вещи интуитивно понятнее и удобнее дельфей и вижуал-студии.
4) Надо написать хотя бы одну полноценную прогу на этом деле, чтобы таки осознать, стоит дергаться ради галочки "можно писать кроссплатформенный GUI".

Comments

[zamotivator.livejournal.com]

Производительность фреймворка - недостаток?
В любом случае, готов обсуждать устриц лишь с тем, кто их ел.
+ биндинги никто не отменял. А хорошая архитектура ложится в любой язык. Огромное количество биндингов потверждает интепорабельность архитектуры и дизайна кути к любому языку программирования.

[kiryl.livejournal.com]

Для производительности придумали C.

[max-posedon.livejournal.com]

Увы, Qt работает быстрее gtk, и быстрее gtk+cairo.

[kiryl.livejournal.com]

Пруфлинк?

[max-posedon.livejournal.com]

Да их же тысячи, + личный опыт + посмотрите на embedded, ну ладно, вот один:

http://zrusin.blogspot.com/2006/10/benchmarks.html

Тема обсасана была уже тысячу раз по этому поводу всюду.

[kiryl.livejournal.com]

Линк давно протух. Что-нибудь по-актуальней видели?

[max-posedon.livejournal.com]

Приведите хоть один обратный. Ну хотябы чтобы вам голословным не быть.

[kiryl.livejournal.com]

Я не утверждал, что gtk быстрее Qt. Это вы утверждали обратное.

[max-posedon.livejournal.com]

И привёл ссылку. А вы всё троллите,

[zamotivator.livejournal.com]

готов обсуждать устриц лишь с тем, кто их ел.
1) Более строгая типизация даёт более хорошие оптимизации
2) Константность даёт оптимизации
Во всём остальном производительность С и С++ совпадает. При условии нормального компилятора, естественно.

[kiryl.livejournal.com]

6-13% времени исполнения тратится на диспетчеризацию виртуальных функций. http://www.cs.ucsb.edu/~urs/oocsb/papers/oopsla96.pdf

[metaclass.livejournal.com]

Вот счас забиватор тебя на эту тему загнобит, готовься. :)

А вообще, там где есть надобность в виртуальных функциях, обычно не до производительности, скажем так. Там больше внимания уделяется кошерности архитектуры и ее поддерживаемости в будущем, нежели мелочам типа 6-13%

[kiryl.livejournal.com]

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

К вопросу о длинне сиволов и дизайне: “well designed” C++ projects with many namespaces, templates, and nested classes can feature names with more than 1,000 characers. One plus point for design, but minus 100 points for performance." (C) Ulrich Drepper

[metaclass.livejournal.com]

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

[max-posedon.livejournal.com]

И не будет, это тока время старта app.

[kiryl.livejournal.com]

Бывает ещё lazy relocations и dlopen().

[zamotivator.livejournal.com]

Бывает ещё boost::memory_pool, Loki::SmallObjectAllocator.

[theiced.livejournal.com]

Если бывает boost, то надо идти лечиться.

[zamotivator.livejournal.com]

Тролль? Понемаю.
Назови хоть одну кроссплатформенную библиотеку на Си, что покроет всю функциональность буста.

Interprocess, Threads, Filesystem для затравки.
Function, Bind для продолжения.
MPL на закуску.

[kiryl.livejournal.com]

Чисто виндовый подход. Главное найти библиотеку которая делает всё-всё-всё. И неважно, что это монстр.

[zamotivator.livejournal.com]

Смешно.
.NET Framework - помойка, это да. дотНетовский и Дельфятский подход - искать компоненты. Сам по себе подход неплох, реализация подкачала - это точно.
И boost, и qt мне нравятся как раз своей модульностью, продуманостью, и минималистичностью.
Я могу из boost'а собрать лишь один кусочек - boost.threads или boost.interprocess, и лишь его линковать/включать dll/so в сборку.

[zamotivator.livejournal.com]

В qt аналогично, кстати.
З.Ы. я линуксоид, если что =)

[kiryl.livejournal.com]

Если используется динамическая линковка, то длинна имён сказывается на времени запуска.

[zamotivator.livejournal.com]

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

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

[zamotivator.livejournal.com]

В некотором сферическом тесте в вакууме - безусловно.
На моих тестах издержки динамической диспетчиризации в цикле доходили до 40-60% времени.

И ровно столько же времени будет тратиться в эквивалентном коде на Си. Не бывает прироста производительности "нахаляву" - не виртуальная функция, ну так косвенный вызов по указателю на функцию.

В проекте, где я работаю (разработка СУБД) мы отказываемся от динамической диспетчеризации в пользу статической.

На С++ мы это описываем при помощи шаблонов. На Си... На Си нас бы спас только кодогенератор.

И это сравнение не пользу Си, удобства разработки на нём.

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