Переделал класс на статические члены - получил сегфолт

Динамический член. Это как?

С терминологией у вас тебя мил человек.

А бага, в том, что два раза объект ты удаляешь.

QWidget::~QWidget()

Destroys the widget.

All this widget's children are deleted first. The application exits if this widget is the main widget.

Вызывая setParent, ты указываешь виджету удалять всех детей при его удалении. Но так как дети не динамически выделены, ты пытаешься удалять то, что не выделял.

Совет тебе дали верный, но для нормального Си++. Но Си++ с Qt, да и с Gtkmm, странный. Ради борьбы с утечками авторы тулкитов ввели свои механизмы управления памятью, которые идут вразрез с обычным подходом в Си++.

То есть получается, что в Qt нельзя статическому члену класса задавать parent на объект своего класса, который для него и является родительским???

Потому что в этом случае мы всегда получим сегфолт при удалении объекта, ибо будут пытаться удаляться статические члены??

Проблема с порядком удаления объектов. Parent'ы удаляются раньше child'ов и удаляют их в своих деструкторах. Но объекты стековые, что и вызывает сегфолт. Либо выделяй память динамически, либо поменяй порядок переменных так, чтобы child'ы удалялись первыми.

Не статическому, а стековому. Статический это совсем другое.

Можно, нужно посто поменять порядок переменных так, что были parent'ы были сверху. Тогда child'ы будут удаляться первыми, и сегфолта не будет.

Не статическому, а стековому. Статический это совсем другое.

Да, я неправильно написал.

Можно, нужно посто поменять порядок переменных так, что были parent'ы были сверху.

Имеется в виду поменять порядок в хидерах?

Так у меня парентом является сам объект, а чилдами являются стековые члены этого же объектного класса. Как я смогу поменять порядок?

Когда ты запихиваешь виджеты в другой виджет и layout, он автоматически становится его child'ом. Т.е. у тебя QToolButton'ы - child'ы QToolBar'ов, а они - child'ы QVBoxLayout. Все они создаются на стеке внутри одного класса и удаляются в порядке, обратном тому, в котором они расположены в определении класса. Выходит так, что QVBoxLayout удаляется первым, и пытается удалить свои child'ы QToolBar, которые созданы на стеке, что приводит к сегфолту.

И да, тебе не нужно делать setParent(this) для стековых переменных, они удаляются автоматически.

Не знаю внутренностей Qt. Похоже, что так. В любом случае просто посмотри, как советуют делать в мануале.

Когда ты запихиваешь виджеты в другой виджет и layout, он автоматически становится его child'ом. Т.е. у тебя QToolButton'ы - child'ы QToolBar'ов, а они - child'ы QVBoxLayout. Все они создаются на стеке внутри одного класса и удаляются в порядке, обратном тому, в котором они расположены в определении класса. Выходит так, что QVBoxLayout удаляется первым, и пытается удалить свои child'ы QToolBar, которые созданы на стеке, что приводит к сегфолту.

Ага, примерно к этому я щас и пришел.

И да, тебе не нужно делать setParent(this) для стековых переменных, они удаляются автоматически.

В моем случае нужно, потому что кнопки и другие крутилки имеют object-имена и работа с ними при размещении на тулбаре происходит по имени, через поиск Qt-объекта в момент инициализации тулбара.

Во всех мануалах практически все примеры написаны через указатели.

Когда ты запихиваешь виджеты в другой виджет и layout, он автоматически становится его child'ом. Т.е. у тебя QToolButton'ы - child'ы QToolBar'ов, а они - child'ы QVBoxLayout. Все они создаются на стеке внутри одного класса и удаляются в порядке, обратном тому, в котором они расположены в определении класса. Выходит так, что QVBoxLayout удаляется первым, и пытается удалить свои child'ы QToolBar, которые созданы на стеке, что приводит к сегфолту.

В общем, в заголовке разместил перечень объектов так:

- Слой, содержащий тулбары
- Тулбары
- Кнопки и крутилки

Раньше было наоборот, но я и предположить не мог, что последовательность описания объектов в хедере может иметь хоть какое-то значение.

И не зря. И не только в мануалах, но и в книгах сказано, что надо тебе использовать динамическое выделение памяти когда ты сталкиваешься с деревом классов Qt. Так надо и все, создатели фреймворка говорят так прыгать. Qt сам за тебя разрулит когда и каких child-ов parent-ов удалять. Он обожает рулить, как и любой фреймворк.