Re: [boost] [Boost Review] Property Tree Library

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-04-20 16:23:39

> Whenever your users prefer a GUI to a text editor ?
> I currently an application for a configurable manufacturing process.
> Various parameters can be tuned interactively, and when good results
> are obtained, the current parameters can be saved into a configuration
> file.
> Another file stores a series of coordinates defining some
> reference positions used by my robotic system.  There is no way
> that I would want to type in those coordinates by hand !!
>
> : > that uses both libs: program_options to handle command-line
> : > parameters, and ptree as a storage format for its data files.
> :
> : program_options has is't own facility for that.
>
> But it can only read it, right?
>
> : > I agree with many of your other points.  In particular ptree
> : > could be made leaner, and the double-indexing may well be
> : > overkill (I haven't looked at the implementation itself).
> : > But the needs the library seeks to address are very real.
> :
> : Could be. But PO already doing everything this library does. Any
> specific
> : examples of what is missing (other than some extra parsers for xml and
> : registry)?
>
> The data I need to store often includes arrays, or even tree-like
> structures.  How would I handle this with program_options ??
>
> Using a library similar to ptree, I have also been storing
> complete "scene graphs" as text files (i.e. a hierarchical
> collection of objects, each stored with a transformation
> matrix, paths to mesh and texture files, and more...).
> The scene was edited graphically at most times, but having
> the textual representation was convenient for some manual
> touch-ups, and of course for tracking changes in a revision
> control system.
>
> I haven't written a single large application where I haven't
> felt the need to use a library similar to ptree -- and done
> it with very obvious benefits.
>
> I might not switch over to ptree, because I am not fond
> of some of its design aspects.  But it definitely has uses
> that go beyond the scope of the provided "tutorial" example.
> Uses that program_options does not support...

All of above could (should?) be implemented more conviniently using 
Serialization Library. I believe program runtime parameters support has 
different goals and rationale. If you need bidirectional permanent store for 
some application state data - use serilization lib. If you need to read 
configuration from different sources and potencially only part of it  - you 
need different solution. The difference is that in first case there is a 
direct correspondance between data in permanane storage and it's 
presentation at runtime within application (hence bidirectional). In later 
case I may have parametes comming from different sources conflict with each 
other and I may want ot use only 1 in 1000 of them. And this is runtime 
parameters domain. Intended to be covered by PO library (failed IMO, but 
again that's a different story)

Gennadiy