Есть ли альтернатива Qt для создания GUI? (остальные фишки(Cеть, Xml итп) не интересуют).
Интересует нормальное (не надо каждый widget в heap выделять, а потом еще и думать стал он чьим-то child'ом или нет и огребать утечки памяти) управление ресурсами.
Здравствуйте, HolyNick, Вы писали:
HN>Есть ли альтернатива Qt для создания GUI? (остальные фишки(Cеть, Xml итп) не интересуют). HN>Интересует нормальное (не надо каждый widget в heap выделять, а потом еще и думать стал он чьим-то child'ом или нет и огребать утечки памяти) управление ресурсами.
Есть U++, я часто пользуюсь, когда надо быстро что-то простое сделать и чтоб получился один файл без всяких DLL. Всё есть, кроме встраиваемого браузера (а-ля QtWebkit). В теории, можно приделать Chromium Embedded Framework и будет этакий Qt с лицензией BSD
А насчёт утечек и думать... вы же на C++ пишете, думать просто необходимо Хотя куда уж проще управление жизнью объектов как в Qt с их QObject
Здравствуйте, sheep2k, Вы писали:
S>Здравствуйте, HolyNick, Вы писали:
HN>>Есть ли альтернатива Qt для создания GUI? (остальные фишки(Cеть, Xml итп) не интересуют). HN>>Интересует нормальное (не надо каждый widget в heap выделять, а потом еще и думать стал он чьим-то child'ом или нет и огребать утечки памяти) управление ресурсами.
S>Есть U++, я часто пользуюсь, когда надо быстро что-то простое сделать и чтоб получился один файл без всяких DLL. Всё есть, кроме встраиваемого браузера (а-ля QtWebkit). В теории, можно приделать Chromium Embedded Framework и будет этакий Qt с лицензией BSD
S>А насчёт утечек и думать... вы же на C++ пишете, думать просто необходимо Хотя куда уж проще управление жизнью объектов как в Qt с их QObject
Вообще, я на стеке стараюсь все(child виджеты) размещать, но чего-то вчера ночью переклинило, что оно не работает)))
Хипа просто стараюсь избегать, не потому что не знаю что да как, а так — на всякий случай.
Здравствуйте, HolyNick, Вы писали:
HN>Вообще, я на стеке стараюсь все(child виджеты) размещать, но чего-то вчера ночью переклинило, что оно не работает))) HN>Хипа просто стараюсь избегать, не потому что не знаю что да как, а так — на всякий случай.
На какой такой "всякий" случай? С какими проблемами вы сталкивались? Расскажите, мне правда очень интересно.
Если вы читали доки по фундаментальным основам Qt то вы должны понимать, что создавая объекты в хипе и передавая им правильных родителей, вам не нужно будет беспокоиться об утечках памяти. В довесок ко всему есть такие замечательные классы, как QPointer, QScopedPointer, QSharedPointer. Если всё это дело "правильно готовить" — то проблем не будет. Впрочем, как и с любой другой библиотекой, которая помогает соблюдать принцип RAII.
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, HolyNick, Вы писали:
HN>>Вообще, я на стеке стараюсь все(child виджеты) размещать, но чего-то вчера ночью переклинило, что оно не работает))) HN>>Хипа просто стараюсь избегать, не потому что не знаю что да как, а так — на всякий случай.
SaZ>На какой такой "всякий" случай? С какими проблемами вы сталкивались? Расскажите, мне правда очень интересно.
SaZ>Если вы читали доки по фундаментальным основам Qt то вы должны понимать, что создавая объекты в хипе и передавая им правильных родителей, вам не нужно будет беспокоиться об утечках памяти. В довесок ко всему есть такие замечательные классы, как QPointer, QScopedPointer, QSharedPointer. Если всё это дело "правильно готовить" — то проблем не будет. Впрочем, как и с любой другой библиотекой, которая помогает соблюдать принцип RAII.
Heap вообще стараюсь избегать, а не в именно в Qt. Qt только начал осваивать. Особых проблем пока не было.
Но вот например если создавать виджеты в стеке, что мне больше нравится ( и более привычно, тк в своей GUI-либе я так и делал), то постоянно надо следить чтобы они были объявлены в нужном порядке, что лишний геморрой. Как альтернатива — все создавать в хипе, что просто исторически непривычно.
ps: Не знаю приходилось ли Вам искать утечки памяти в хипе, которые вызывают завал программы, который очень сложно искать, а мне приходилось (редко правда).
Процедура не самая приятная. Поэтому обилие new new new в Qt немного напрягло.
А работать(выделять widget'ы на ) на стеке похоже еще более небезопасно (ошибся в порядке объявления объектов и сразу получил delete где-то в стеке).
Здравствуйте, HolyNick, Вы писали:
HN>ps: Не знаю приходилось ли Вам искать утечки памяти в хипе, которые вызывают завал программы, который очень сложно искать, а мне приходилось (редко правда). HN>Процедура не самая приятная. Поэтому обилие new new new в Qt немного напрягло.
Приходилось. Знаю, что leak detector-ы очень не любят Qt, особенно если приходится использовать всякие deleteLater. Но, я же не просто так написал про смарт поинтеры.
А вообще, в случае таких загонов стоит задуматься о том, чтобы не писать на С++, а выбрать другой язык, со встроенным GC. C# или Java, например.
HN>А работать(выделять widget'ы на ) на стеке похоже еще более небезопасно (ошибся в порядке объявления объектов и сразу получил delete где-то в стеке).
Вот поэтому и нужно делать так, как задумано. А не изобретать велосипеды.
Здравствуйте, HolyNick, Вы писали:
HN>Есть ли альтернатива Qt для создания GUI? (остальные фишки(Cеть, Xml итп) не интересуют). HN>Интересует нормальное (не надо каждый widget в heap выделять, а потом еще и думать стал он чьим-то child'ом или нет и огребать утечки памяти) управление ресурсами.
Здравствуйте, HolyNick, Вы писали:
HN>Есть ли альтернатива Qt для создания GUI? (остальные фишки(Cеть, Xml итп) не интересуют). HN>Интересует нормальное (не надо каждый widget в heap выделять, а потом еще и думать стал он чьим-то child'ом или нет и огребать утечки памяти) управление ресурсами.
Можно Qt биндинги для managed-языка использовать. Питон, например. Думать, предположительно, не надо.
Здравствуйте, savitar, Вы писали:
S>Здравствуйте, HolyNick, Вы писали:
S>>>Есть U++, я часто пользуюсь, когда надо быстро что-то простое сделать и чтоб получился один файл без всяких DLL.
S>а как там с Unicode/UTF-8? посмотрел примеры, там PromptOK("Hello world")
Для Unicode у них есть своё решение, кроме того, полно функций как в Qt, которые позволяют решить почти любую проблему.
Чем мне нравится U++, так это тем, что код получается очень компактный, сама среда с библиотеками собирается из исходников элементарно и очень быстро, багфиксы выкладываются почти каждый день. Сторонние библиотеки пристёгиваются достаточно просто.
Хотя сама среда (TheIDE) несколько непривычна и без неё собрать своё приложение никак не получится. И документация не такая роскошная, как в Qt.
Впрочем, обсуждение U++ слегка выбивается из темы Qt
Здравствуйте, HolyNick, Вы писали:
HN>Вообще, я на стеке стараюсь все(child виджеты) размещать, но чего-то вчера ночью переклинило, что оно не работает))) HN>Хипа просто стараюсь избегать, не потому что не знаю что да как, а так — на всякий случай.
На стеке можно располагать только модальные окна, поскольку их время жизни ограничено временем жизни данного фрейма стека.
Немодальные окна ты обязан располагать в хипе, поскольку время их жизни заранее неизвестно.
Так что либо в хипе, либо внутри других окон, как член, но это другое окно -- всё равно в хипе, и так далее.
Исключение составляет только главное окно приложения, оно в main.
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, HolyNick, Вы писали:
HN>>Heap вообще стараюсь избегать...
SaZ>Зачем?
Не говорю уже про возможные утечки, трудно находимые...будем считать, что умными указателями все это можно на 99% устранить. Хотя если Вы "программируете" пилотируемый космический корабль 99% может быть недостаточно.
Здравствуйте, MasterZiv, Вы писали:
MZ>Здравствуйте, HolyNick, Вы писали:
HN>>Вообще, я на стеке стараюсь все(child виджеты) размещать, но чего-то вчера ночью переклинило, что оно не работает))) HN>>Хипа просто стараюсь избегать, не потому что не знаю что да как, а так — на всякий случай.
MZ>На стеке можно располагать только модальные окна, поскольку их время жизни ограничено временем жизни данного фрейма стека. MZ>Немодальные окна ты обязан располагать в хипе, поскольку время их жизни заранее неизвестно. MZ>Так что либо в хипе, либо внутри других окон, как член, но это другое окно -- всё равно в хипе, и так далее. MZ>Исключение составляет только главное окно приложения, оно в main.
Спасибо, это я понимаю.
MZ>...либо внутри других окон, как член, ...
Ну, вот я так и делал. Просто меня переклинило(было поздно ), что в этом случае для всех child'ов будет вызван delete. (а этого не произойдет ибо они "отрегистрируются" от своего parent'a раньше, чем будет вызван деструктор(где по умолчанию, насколько я представляю, вызывается delete для всех зарегистрированных child'ов) QObject).
Здравствуйте, HolyNick, Вы писали:
SaZ>>Здравствуйте, HolyNick, Вы писали: HN>>>Heap вообще стараюсь избегать... SaZ>>Зачем?
HN>А зачем лишний раз тратить(медленнее чем на стеке) время на выделение памяти(из heap), если в этом нет необходимости?
Можно я буду ссылками отвечать? А то вы говорите, но не можете привести ни одного аргумента по теме. Вы занимаетесь преждевременной оптимизацией
.
Сделайте простейшее GUI приложение, написанное на Qt и сравните время, которое тратится на отрисовку UI и время, которое тратится на выделение памяти из кучи. Результат вас удивит, я думаю.
Здравствуйте, HolyNick, Вы писали:
HN>Не говорю уже про возможные утечки, трудно находимые...будем считать, что умными указателями все это можно на 99% устранить. Хотя если Вы "программируете" пилотируемый космический корабль 99% может быть недостаточно.
Что-то вас занесло...
Ещё вам стоит подумать, чем должны отличаться стандарты кодирования при программировании космических кораблей и сайтов визиток. Где-то была весёлая статья, только не могу вспомнить ссылку.
Хотя куда уж проще управление жизнью объектов как в Qt с их QObject 
