Re: [boost] Do really property_tree and program_options overlap?

From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-21 15:54:12

Hi Vladimir,

>> 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 
> name,
> 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 
conversions.

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 
any_cast).

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.

Best regards,
Marcin