Самым большим достоинством property_tree является простой в использовании интерфейс. Если мы попытаемся сделать его родовым деревом, он будет скомпрометирован.

Я имею в виду, почему мне нужно это полуиспеченное дерево как другая структура данных? Дерево собственности само по себе ничего не поддерживает. Это всего лишь структура данных. У вас есть парсеры, которые производят дерево собственности из разных источников. Но вы также создаете карты или что-то еще. Вот, например, все, что мне нужно сделать, чтобы «внедрить» такую же функциональность, как ваше дерево свойств:

То, что вы только что реализовали, является упрощенной версией property_tree, которая, среди прочего, не позволяет создавать редактируемые человеком XML-файлы. Теперь добавьте больше интерфейса (aka get functions), добавьте больше архивов в lib сериализации, добавьте кастомизацию, добавьте прозрачный перевод из строк в произвольные типы и наоборот. Проведите несколько недель, пытаясь исправить все угловые случаи, а затем еще несколько недель, пытаясь сгладить грубые края в интерфейсе. Затем напишите тесты. Пишите документы. В конце концов, я думаю, вы не получите гораздо меньше кода, чем в библиотеке уже есть. Вы можете сэкономить, используя мультииндекс вместо ручной индексации.

Хотя дерево имеет большой интерфейс со многими функциями, изменяющими состояние дерева, оно использует подход «единой точки изменения». Каждая вставка в конечном итоге проходит через одну функцию, которая заботится о безопасности исключений и синхронизации индекса с данными. То же самое относится и к стиранию. Эта функция имеет 9 строк кода в случае вставки, и (по совпадению) также 9 в случае стирания. При использовании мульти-индекса эти функции, очевидно, будут упрощены, возможно, до 4 строк каждая. Чистая прибыль: 10 строк кода (из нескольких сотен в ptree_implementation.hpp).

Я знаю, что есть прирост производительности, но в то время я сосредоточился на том, чтобы сделать интерфейс правильным.

Я думаю, что важно сосредоточиться на интерфейсе в обзоре, но я также вижу несколько преимуществ реализации, которая основывается на Boost. MultiIndex:

Я еще не использовал опции программы. Но если я правильно понимаю, обе библиотеки поддерживают хранение и доступ к данным со строками, которые могут описывать какую-то иерархию. Это, кажется, основная идея обеих библиотек - это правильно?

Что я сам использовал вашу библиотеку дерева свойств для чтения и записи файла конфигурации. Это действительно было очень легко использовать. Однако было бы еще проще, если бы это было что-то, что я знал раньше, например, итератор. На данный момент я определенно буду использовать вашу библиотеку дерева свойств, но я был бы признателен, если бы существующие концепции были повторно использованы многими разработчиками C++. Я считаю, что ваша библиотека должна быть частью Boost, но должна быть более обобщенной в будущем.

Правильно, но реальная ценность приходит, когда кто-то разрабатывает хороший STL-подобный интерфейс и пишет документы и т. Д., По крайней мере, это было моей точкой зрения.

ИМО Торстен совершенно прав. Это именно то, что можно добавить в библиотеку в рамках ее текущего обслуживания и развития (без обзора, конечно).

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

Если есть такой доброволец, я могу оказать ей помощь/наставничество. Мне также интересно, подходит ли эта задача для Google Summer of Code.

Я думаю, что это было бы хорошо для SOC. B.MI заботится обо всех действительно трудных вещах, и поэтому для студента представляется разумным заполнить детали.

Пожалуйста, напишите предложение!

Я только что это сделал:

<And then... after long hours of coding (and fun) this library saw the light.>