Я согласен с Андри и нахожу документацию property_tree крайне минимальной.Мне понадобилось ptree для загрузки идентичных объектов с разными настройками, и я не мог понять, что повторяет итератор, какой тип он возвращает, и останется ли он на уровне объектов, или будет проходить через каждый узел, похожий на BFS.Наконец, мне удалось заставить мой код работать для случая, подобного следующему:
файл настроек:
<object1>
<enable>true</enable>
<label>hello</label>
</object1>
<object2>
<enable>false</enable>
<label>goodbye</label>
</object2>
Сначала я добавил конструктор для моего объекта, который можно инициализировать вPtree.Обратите внимание, что я использую опцию get with default, чтобы предотвратить исключение при сбое get ():
object::object(const boost::property_tree::ptree &pt_)
{
enable = pt_.get<bool>("enable", true); // usage is: get<type>(path, default)
label = pt_.get<std::string>("label", "empty");
}
Наконец, следующий код загружает оба объекта и помещает их в карту:
std::map<std::string, my_object> objects_map;
// parse settings file and add loggers
if(filesystem::exists(logger_settings_file))
{
boost::property_tree::ptree pt;
read_xml(logger_settings_file, pt);
BOOST_FOREACH(boost::property_tree::ptree::value_type &v, pt)
{
objects_map[v.first] = my_object(v.second);
}
}
Итак, чтобы ответить на мои собственные вопросы:
- Итератор перебирает файл настроек, не опускаясь на более низкие уровни.Запустив приведенный выше код, вы обнаружите, что цикл повторяется дважды - по одному разу для каждого объекта в файле XML.
- Итератор возвращает объект value_type, который напоминает пару, и имеет
first
и second
аксессоры.v.first
- это std :: string, содержащая родительский узел (в моем случае «object1», «object2»), а v.second
- это boost::property_tree::ptree
, который можно использовать для анализа полей объекта.