Здравствуйте, HolyNick, Вы писали:
HN>Почему "все равно в хипе" не ясно...теоретически все окна могут быть на стеке насколько я понимаю.
Потому что для немодальных окон нужно будет изобретать сложный костыль. Потому что запутаетесь в паттерне dependency injection.
И главное, потому что не сможете динамически создавать окна. Вот простой пример: вам надо сделать поддержку пользовательских кнопочек на тулбаре. Так чтобы на каждую кнопку пользователь мог повесить, например, эмуляцию какого-либо сочетания клавиш. Т.е. количество кнопок определяет пользователь.
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, HolyNick, Вы писали:
SaZ>>>Здравствуйте, HolyNick, Вы писали: HN>>>>Heap вообще стараюсь избегать... SaZ>>>Зачем?
HN>>А зачем лишний раз тратить(медленнее чем на стеке) время на выделение памяти(из heap), если в этом нет необходимости?
SaZ>Можно я буду ссылками отвечать? А то вы говорите, но не можете привести ни одного аргумента по теме. Вы занимаетесь преждевременной оптимизацией
. SaZ>Сделайте простейшее GUI приложение, написанное на Qt и сравните время, которое тратится на отрисовку UI и время, которое тратится на выделение памяти из кучи. Результат вас удивит, я думаю.
Я говорил, что СТАРАЮСЬ(почему? сказал выще) не использовать heap (не только в QT, а в принципе), если не вижу в этом необходимости. Это мое предпочтение, я не пытаюсь Вас в этом убедить.
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, HolyNick, Вы писали:
HN>>Не говорю уже про возможные утечки, трудно находимые...будем считать, что умными указателями все это можно на 99% устранить. Хотя если Вы "программируете" пилотируемый космический корабль 99% может быть недостаточно. SaZ>Что-то вас занесло...
SaZ>Тоже оставлю ссылок: SaZ>1) RAII SaZ>2) Стандарты кодирования применяемые при программировании Curiosity SaZ>3) Про смарт поинтеры, наконец, почитайте
SaZ>Ещё вам стоит подумать, чем должны отличаться стандарты кодирования при программировании космических кораблей и сайтов визиток. Где-то была весёлая статья, только не могу вспомнить ссылку.
Спасибо за ссылки.
Если обратите внимание, в моем посте есть упоминание о "умных указателях", поэтому Ваш пункт 3) немного странный.
Возможно, Вам нужно ему последовать тоже или внимательней читать посты.
Стандарты кодирования в Curiosity — это отлично. Если там где-то написано, что "желательно\лучше использовать heap где попало" соглашусь с ним и буду "всегда так делать".
Здравствуйте, SaZ, Вы писали:
SaZ>Сделайте простейшее GUI приложение, написанное на Qt и сравните время, которое тратится на отрисовку UI и время, которое тратится на выделение памяти из кучи. Результат вас удивит, я думаю.
Оно(GUI приложение) будет работать медленнее, чем GUI с выделением объектов на стеке. Да, это не будет заметно.
Планирую на следующей неделе выложить статью на Хабр по некоторым моментам U++, его и советую, хотя с Qt не работал, да и не манит.
Из крутого: TreeCtrl с drag-and-drop; SQL схоже с подходом php::Yii; свой формат QTF для ReportView (в Qt вроде отсылают к сторонней либе) и надписей для некоторых контролов; делегаты (настолько с ними приятно работать, что ничего больше не надо); библиотека из Bazzar для работы с Excel/Word и Open Office' аналогами.
HN>Вообще, я на стеке стараюсь все(child виджеты) размещать, но чего-то вчера ночью переклинило, что оно не работает))) HN>Хипа просто стараюсь избегать, не потому что не знаю что да как, а так — на всякий случай.
Как только ты займешься компоновкой (QLayout), то об автоматических QWidget-aх придется забыть, поскольку компоновщик переопределяет владельца содержащихся в нем QWidget-ов при вызове QWidget::setLayout.
А так, концепция владения в Qt настолько мощная, что когда ты в нее въедешь, то это будет почки Java в плане управления автоматической сборкой мусора.
Там в комментах приводили ссылку на сравнение кода. Мне очень не понравилось, чувствуется рекламная составляющая. Мол "смотрите, насколько с нами проще", а по факту, единственное отличие в трудоёмкости — так это то, что в U++ при создании элементов UI все параметры передаются в одну строку, а в Qt — в несколько строк (вызовов методов). Учитывая то, что в Qt очень хорошо продуманы значения по-умолчанию и далеко не всегда нужно указывать всю пачку значений, "преимущества" в стиле кодирования U++ становятся не так очевидны. По сути, можно написать пачку макросов для Qt, которые ужмут код до нескольких строк.
Сам лично U++ не ковырял, но чувствую, что с реализацией нетривиальных контролов там всё будет намного сложнее, чем с Qt.
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, ST1, Вы писали:
ST1>>Впечатления от знакомства с Ultimate++
SaZ>Там в комментах приводили ссылку на сравнение кода. Мне очень не понравилось, чувствуется рекламная составляющая. Мол "смотрите, насколько с нами проще", а по факту, единственное отличие в трудоёмкости — так это то, что в U++ при создании элементов UI все параметры передаются в одну строку, а в Qt — в несколько строк (вызовов методов). Учитывая то, что в Qt очень хорошо продуманы значения по-умолчанию и далеко не всегда нужно указывать всю пачку значений, "преимущества" в стиле кодирования U++ становятся не так очевидны. По сути, можно написать пачку макросов для Qt, которые ужмут код до нескольких строк.
SaZ>Сам лично U++ не ковырял, но чувствую, что с реализацией нетривиальных контролов там всё будет намного сложнее, чем с Qt.
К сожалению, удобство за счет компактного вызова методов по цепочке нивелируется проблемами даже базовых контролов. Например, в GridCtrl нельзя изменить размер строк в хедере, возникают ошибки при объединении ячееек; в дереве есть артефакты смещения узлов при изменении размера шрифта и прочие неудобства, исправить которые самостоятельно мне было трудно и приходилось теребить разработчиков, в то время как заказчик недоумевал, почему привычные ему вещи из Html, вроде многослойной картинки нереализуемы. Из моих 75 постов на форуме за месяц большинство относилось либо к примерам, где я воспроизводил баг, либо к поиску недокументированных опций чтобы сделать очередную "тонкую настройку". А хотелось бы, чтобы в ответах были отсылки к докам...
Так что после экспериментов с U++ я зауважал Qt (никогда не программировал на нем, но имел определенные снобизм как к массовому явлению), так как скорее всего уже бы закончил проект.
Здравствуйте, HolyNick, Вы писали:
SaZ>>Сделайте простейшее GUI приложение, написанное на Qt и сравните время, которое тратится на отрисовку UI и время, которое тратится на выделение памяти из кучи. Результат вас удивит, я думаю.
HN>Оно(GUI приложение) будет работать медленнее, чем GUI с выделением объектов на стеке. Да, это не будет заметно.
1. Не будет, потому что первое же обращение к оконному менеджеру через сокеты(пусть даже UNIX domain) нивелирует все задержки на выделение в куче.
2. Ну и наконец когда вы на стеке выделяете например кнопку — её потроха все равно выделяются в куче
3. Если вы пишете "пилотируемый космический корабль" и выделяете все на стеке — у вас кончится стек.
Недавно (2013) появился новый игрок — Nana C++. Релизует кроссплатформенное GUI для C++11.
На русском про библиотеку ничего нет.
Еще не пробовал, т.к. требуется VS2013.
Мне кажется, у нее большое будущее, хотя бы потому, что по духу она близка WTL.
В 2008 были попытки воплотить нечто подобное в eGUI++
Собственно, на вопрос уже ответили. Зачем повторяться.
Фрэймворк нужно выбирать исходя из задач и из бюджета. Если вся команда хорошо знает WPF, то далеко не факт, что она сможет качественно что-то реализовать на Qt.
