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

Вопрос — а в чем лучше держать дерево?

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

Если писать дерево самому — то вроде это решение более заточено для конкретной задачи, соответственно доступ к атрибутам не в рантайме типа xmlnode-
>getAttribute("name") а напрямую node->name; требуется код загрузки из xml и сохранения в xml; также при сохранении xml файл регенерируется полностью с нуля, то есть в нем теряются например комментарии и нестандартные теги/атрибуты (не знаю понадобится ли такое но вдруг).

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

Здравствуйте, x-code, Вы писали:

XC>Пока непонятно во что все выльется в проекте в дальнейшем, но решение хорошо бы принять сейчас. Возможно есть какие-то плюсы и минусы о которых я пока не знаю.

Когда понадобится что-то поболее xmlNode->setAttribute, переход будет мучительно больным.

Парсер должен уметь доставать все эти аттрибуты, комментарии и прочее, так что в своем представлении их можно сохранить.
А можно и скрестить плюсы и минусы обоих подходов и сделать врапперы вокруг xml дерева.

Здравствуйте, x-code, Вы писали:

XC>Требуется в памяти держать дерево (наподобие дерева файлов или классов в любой IDE)

Сначала разобраться, требуется ли дерево в памяти или его визуальное представление.
дерева файлов или классов в любой IDE — это визуальные представления.

XC>Дерево загружается из xml файла и в него же сохраняется. Также с ним из программы могут проводиться некие манипуляции, вроде добавления, удаления и переименования узлов, изменения их атрибутов.

XC>Вопрос — а в чем лучше держать дерево?

В любом обычном объектно-ориентированно написанным сколько нибудь сложном приложении приложении и так есть иерархически связанные объекты, чем не дерево.
Наверное какие то из этих классов дол;ны иметь методы чтения-записи XML вместе с подобъектами.

XC>Если держать собственно в xml документе — то плюсы в том что вроде как все из коробки (xml библиотека предоставляет набор классов), при сохранении не теряются xml-комментарии и нестардартные теги/атрибуты, но доступ медленнее, и свой код прямо в классы узлов дерева не поместить.

Не надо так делать. Когда появился XML по наивности пытались навернуть иерархию как раз классов, предназначенных для конфигурации над XML DOM но решение получается переусложненным и излишне тяжелым.

XC>Если писать дерево самому — то вроде это решение более заточено для конкретной задачи, соответственно доступ к атрибутам не в рантайме типа xmlnode-
>>getAttribute("name") а напрямую node->name; требуется код загрузки из xml и сохранения в xml; также при сохранении xml файл регенерируется полностью с нуля, то есть в нем теряются например комментарии и нестандартные теги/атрибуты (не знаю понадобится ли такое но вдруг).

Какой язык?
Если нужно дерево в памяти в нормальных языках есть готовые шаблонные классы, дерево реализуется парой строчек.
Если нужно визуальное дерево, то опять же везде есть реализации.
далее выбрать под свои требования (по скорости, занимаемой памяти и т.п.).
Хранение в XML реализуется с помощью какого нибудь парсера и его DOM, но это дерево XML должно создаваться только на момент чтения — записи конфигурации,
свои классы доложны читать-писать туда информацию, и только в момент загрузки / сохранения.

Также во многих языках есть автоматическая сериализация, настраиваемая декларативно. ее обычно хватает для несложных случаев.

XC>Пока непонятно во что все выльется в проекте в дальнейшем, но решение хорошо бы принять сейчас. Возможно есть какие-то плюсы и минусы о которых я пока не знаю.

Здравствуйте, swame, Вы писали:

S>Сначала разобраться, требуется ли дерево в памяти или его визуальное представление.
S>дерева файлов или классов в любой IDE — это визуальные представления.

Нужно и визуальное представление, и дерево в памяти. Понятно что на визуальном представлении отображаться будет не все что есть в памяти.

S>Какой язык?

C++/Qt

Здравствуйте, x-code, Вы писали:

XC>Здравствуйте, swame, Вы писали:

S>>Сначала разобраться, требуется ли дерево в памяти или его визуальное представление.
S>>дерева файлов или классов в любой IDE — это визуальные представления.

XC>Нужно и визуальное представление, и дерево в памяти. Понятно что на визуальном представлении отображаться будет не все что есть в памяти.

S>>Какой язык?

XC>C++/Qt

Нужно решить, что есть модель в программе: xml-документ или абстрактное дерево, а xml-документ это всего лишь носитель данных. Что подходит то и выбираем. Возможен вариант совмещающий оба подхода.

Здравствуйте, Qulac, Вы писали:

Q>Нужно решить, что есть модель в программе: xml-документ или абстрактное дерево, а xml-документ это всего лишь носитель данных. Что подходит то и выбираем. Возможен вариант совмещающий оба подхода.

Абстрактное дерево. xml это лишь способ хранения. Можно было бы json выбрать или что-то еще, без разницы.

Здравствуйте, x-code, Вы писали:

Q>>Нужно решить, что есть модель в программе: xml-документ или абстрактное дерево, а xml-документ это всего лишь носитель данных. Что подходит то и выбираем. Возможен вариант совмещающий оба подхода.

XC>Абстрактное дерево. xml это лишь способ хранения. Можно было бы json выбрать или что-то еще, без разницы.

Тоже согласен. Лучше абстрактное дерево, XML это всего лишь способ сериализации и только. XML вообще не должен быть частью дерева. Сейчас нам нужна сериализация в XML, завтра в JSON, потом в бинарный формат, потом в базу данных... И всё будет в одной помойке намешано.

Чего огород городить!?! Это отдельный функционал. А само дерево делается на коленке за пять минут. И главное оно будет вполне абстрактным — именно что дерево. Родитель\детки\обход\удалить, в общем типичный CRUD. И всё. А как оно сериализуется\десерииализуется это отдельная часть.

Здравствуйте, x-code, Вы писали:

XC>Требуется в памяти держать дерево (наподобие дерева файлов или классов в любой IDE)

XC>Пока непонятно во что все выльется в проекте в дальнейшем, но решение хорошо бы принять сейчас. Возможно есть какие-то плюсы и минусы о которых я пока не знаю.

Точно не понадобится потом сохранять не в xml, а в базу данных?

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

Здравствуйте, x-code, Вы писали:

XC>Если держать собственно в xml документе — то плюсы в том что вроде как все из коробки (xml библиотека предоставляет набор классов), при сохранении не теряются xml-комментарии и нестардартные теги/атрибуты, но доступ медленнее, и свой код прямо в классы узлов дерева не поместить.
Не знаю, как в других языках, но в C# объект XmlDocument очень жирный, в разы превышающий объем исходного Xml.