Qt: как принято имплементировать деревья?

Если с деревом необходимо работать как с моделью, создавая для нее представления - тогда можно унаследоватся от QAbstractModel. Внутри там уже есть механизм «дерева» для элементов. Но подробно я с ним именно в контесте деревьев не работал.

в бусте деревья имеются

но не совсем те

А почему не просто QMap?

Или нужно просто дерево с другими целями?

мне нужно в treeView отображать дерево с произвольной вложенностью подтаблиц.
пока смотрю как сделано тут: http://doc.qt.nokia.com/latest/itemviews-editabletreemodel.html

в примере структура, из которой QAbstractItemModel таскает данные, реализует дерево однотипных объектов на указателях.
в ней у каждой сущности есть QList с указателями на дочерние сущности.

так вот меня терзают смутные сомнения, что если я удалю какой-то подпункт и очищу объекты его детей (как это в примере) - то в памяти зависнут указатели на внуков/правнуков/проч. то есть нужно рекурсивно пробежаться по всем потомкам и по указателям поприбивать объекты. сие наводит на мысль что для сабжа должно быть ченить готовенькое.

При удалении всех потомков для каждого из них произойдет вызов деструктора TreeItem::~TreeItem().

Т.е. при удалении дерево обходится рекурсивно.

верно! хм, я не постиг дао ООП.
привык линейно мыслить процедурами/функциями - что почитать, чтобы проникнуться ООП концепцией?

хм, я не постиг дао ООП

Ты просто не изучил C++, деструкторы к ООП никакого отношение не имеют.

Эээ это уже интересно, то есть объект создали и освобождать от него память не нужно?

А что деструктры уже освоюождают память? И хорошо работают с GC? Или они может быть хорошо взамиодействуют с оптимизацией хвостовых вызовов? Или они могут выполнить освобождение любых ресурсов?

Прежде чем отвечать на последний вопрос рекомендую прочитать close(2).

Прежде чем отвечать рекомендую повторить концепции ООП и узнать, что конструктор и деструктор стандартный элемент ООП подхода неспецифический для языков

«искаропки» контейнера нет - всё ручками

а вообще скажи - что тебя останавливает от написания такого контейнера, по мотивам ATD от дядюшки Аллмана?

то, что такой контейнер могли реализовать в Qt. либо обосновали что такие контейнеры не нужны и предложили серебрянную пулю на замену.
все зыждится на желании писать правильно с соблюдением идеологии, стиля кодирования и проч.

конструктор и деструктор стандартный элемент ООП подхода неспецифический для языков

Конструктор - вещь не специфичная не только для языка, но и для ОО подхода. Покажи мне деструкторы в Java или Smalltalk (да и зачем они там?).

Я в яве не спец, но там емнип есть этот самый finalize(). Или это не то?

Это не то. Этот finalize выполниться тогда, когда GC будет угодно, а деструкторы в C++ - в строго определённые моменты времени и в определённой последовательности.

то, что такой контейнер могли реализовать в Qt. либо обосновали что такие контейнеры не нужны и предложили серебрянную пулю на замену.

вот сидят 100 человек и так каждый рассуждает, а вывод - ССЗБ :) если Вам такой контейнер нужен - делайте

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

нет это всё правильно, но codestyle-nazi - это тоже не надо

>что почитать, чтобы проникнуться ООП концепцией

Буча почитай.

И запомни, пожалуйста. Дерево — это список. Отсюда и возникают «указатели». Все-таки C++ все что угодно в состоянии испоганить.

в каком это месте дерево список? поясни мысль

>в каком это месте дерево список?

О-о-о-о! Ты, браток, до этого доходи сам. И не потому что я такой вредный, а потому что я не знаю как это объяснть. А в С++ этого вообще не видно, мешают «указатели».

конечно мои телепаты подсказывают что ты имеешь ввиду, но даже они не понимают зачем «указатели» брать в кавычки

Угу. А если Вы файл в конструкторе класса открываете, то Вы его, видимо, в finalize() закрываете? Но это ведь не деструктор! Ни в коем случае!

По поводу удаления хочу напомнить, что QObject удаляет всех своих потомков в деструкторе. Поэтому вручную их удалять не надо. Сразу не понял, что вопрос про визуальную модель дерева. Думал, это про структуру данных...

Дерево — это список. Отсюда и возникают «указатели».

больше никогда не пейте бабушкины таблетки, на Вас они вредно влияют

>в каком это месте дерево список?

О-о-о-о! Ты, браток, до этого доходи сам. И не потому что я такой вредный, а потому что я не знаю как это объяснть. А в С++ этого вообще не видно, мешают «указатели».

да ты не очкуй, всё на мази братуха, ты только скажи какой фарер тебе это напел

хм, а я думал это связный граф без циклов

структура данных и есть - никакого QObject. из этой структуры QAbstractItemModel таскает информацию и предоставляет её в treeView

>ты только скажи какой фарер тебе это напел

МакКарти, вообще-то ;)

>ты только скажи какой фарер тебе это напел

МакКарти, вообще-то ;)

если у Вас есть пруф, значит МакКарти - лох

может он имел ввиду, что у каждой _список_ детей и один родитель (кроме корня)?..
а вот у двоичных деревьев список держать смыла нет ради двух детей

Честно говоря, я выпил достаточно много пива, но всё же непонятно, в чём вопрос. Есть же отличные примеры Model-View в Qt

* у каждой ноды (узла тобиш)

может он имел ввиду, что у каждой _список_ детей и один родитель (кроме корня)?. а вот у двоичных деревьев список держать смыла нет ради двух детей

месье, Вы понимаете разницу между деревом и списком, или не вполне?

вполне. я даже разницу между вектором, списком, сетами и мапами вполне представляю, но я сомневаюсь что в кутэ деревья на графах (типа бустовых) сделаны

вполне. я даже разницу между вектором, списком, сетами и мапами вполне представляю, но я сомневаюсь что в кутэ деревья на графах (типа бустовых) сделаны

это прекрасно, но понимаете ли Вы деревья так как их понимают господа: Кормен Т., Лейзерсон Ч., Ривест Р., Штайн К., Ахо А., Хопкрофт Дж., Алман (Ульман) Дж. и др.?

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

ну, тогда, чисто любопытства ради, найдите их труды в сети и посмотрите как они относятся к данному вопросу :)

#include <QObject> таки понадобился - в частности ради плюшек с tr()

Судя по всему файл в яве должен закрывать GC. Так что в какой-то мере я согласен с Begemoth - я яве (или джаве, как там её правильно обзывать) деструкторы не нужны.

Да и в С++ в деструкторе закрывать может быть опасно, если close завершиться с ошибкой (что может быть в случае сетевых ФС, специальных файлов устройств), то следует освобождение ресурса отложить на некоторое время. Метод такого откладывания зависит от программы и реализовывать его в деструкторе нет возможности, параметирезовать же класс потока стратегией откладывания мне представляется неоправданным усложнением.

> Судя по всему файл в яве должен закрывать GC

А ничего что GC может вообще не запуститься ни разу во время работы программы?

Чего конечно, но в случае с файлами их закроет ОС после завершения процесса. Однако файлами дело не ограничивается, закрывать соединения со всякими серверами GC не может.

Ну если нужно отображаемое дерево с контейнером для данных, почему просто не использовать QTreeWidget??
Зачем изобретать велосипед?

Если надо ОЧЕНЬ много данных в дереве держать тогда воспользуйся QTreeView + QAbstractModel, а элементы дерева держи в базе данных. Где-то в инете была специальная моделька для этого.

Ну а для относительно не большого дерева воспользуйся, как я уже говорил, QTreeWidget. У этой штуки много всяких приятностей и удобностей.

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