From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-21 15:54:12
>> Briefly, PO library operates on a flat strings of options, property_tree
>> is a DOM. [...]
> Well, this is generally wrong. The program_options goal is to obtain named
> runtime options from whatever source you can store them. I hope to add
> Win32 Registry or LDAP support in future. Note also that options *are*
> hierarchical, you can use "your_app.window1.button15.width" as option
> if you're so inclined.
I will repeat the same argument I already used in discussion with Gennadyi.
The fact that PO can handle options in form "a.b.c.d" does not make it
hierarchical. How do you manipulate branches in PO, for example how can you
take a branch, make a copy of it and attach somewhere else in hierarchy? How
do you take one branch and make a separate data structure of it?
> [...] require that property_tree make it possible to:
> - Access any node with a fully-qualifed name
> - Allow to store values of any type as nodes.
> The first requirement is already met. The second seems not -- the
> property_tree docs say that operator>> is used by the 'get' methods, while
> program_options used strong typing.
It's the fault of my docs that you think that operator >> is hardcoded. Of
course you can customize it, as well as the data type. Part of the traits is
extractor and inserter function objects, which are used to handle the
Library contains an example (custom_data_type.cpp) where std::string is
replaced with boost::any, and operator << is replaced with any_cast. You can
even use parsers with this combination, as long as you do not put anything
else than a string in boost::any (or provide better extractor than just
And last of all, I do not want to make impression that I try to prove
property_tree makes PO library obsolete, or is generally "better" or
"worse". I only think they cover different problem domain. And as you
pointed out, they could work nicely together.