Я использую Qt designer для разработки пользовательского интерфейса. При реализации дизайна в коде я использую подход множественного наследования. Нет никакой реальной причины, почему я использую этот метод, я просто нашел, что это проще.
Во всяком случае, когда я посмотрел в сгенерированный заголовочный файл, я заметил в функции setupUi (), что все расположено в куче. Мне действительно не нужны объекты, чтобы пережить его родителя и в соответствии с этот, в моем случае это не должно быть выделено в куче.
В ситуациях, когда родительский объект — это просто маленький модальный диалог, размещенный в стеке, не будет ли это пустой тратой того, что его объекты пользовательского интерфейса размещены в куче?
Есть ли обходной путь для этого? Должен ли я просто перестать беспокоиться? Я не нашел ситуации, когда это стало проблемой, но мне все еще интересно. На самом деле, это совсем не проблема. Я просто хочу знать.
Общая практика Qt — использовать выделение кучи для любого объекта QObject, если его время жизни не ограничено текущей областью действия. Это может показаться расточительным, но в контексте создания пользовательского интерфейса любое влияние на производительность будет незначительным.
Также обратите внимание, что из-за широкого использования Qt идиомы pimpl каждый созданный QObject имеет внутренний QObjectPrivate, который всегда выделяется в куче, поэтому просто невозможно сохранить все в стеке.
Поэтому я бы посоветовал вам перестать беспокоиться. 🙂
Хватит беспокоиться … Хотя дизайн QT не исключает сборки набора виджетов в стеке. Существует иерархия владения между родительскими и дочерними виджетами. Родительский виджет владеет всеми его дочерними элементами. Распределение стека может привести к поломке, что приведет к двойному удалению, если распределения не были выполнены в правильном порядке (сначала дочерние), см. Документация QT на эту тему (@Subaru выкопал это), лично для меня такая оговорка обычно означает, что это не очень хорошая идея. Iirc ‘QObject’ и ‘QWidget’ не могут быть скопированы по этой причине.