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

From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-20 13:35:06

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote in message 
news:e287in$lsr$1_at_sea.gmane.org...
:
: > I think that a clear difference is that Property Tree is intended
: > to support I/O of configuration settings, and of other kinds of
: > human-readable data files.  I could well envision an application
:
: The same woth PO. PO doesn't deal with config file generation but that 
(as I
: mention in my review) is completely unnessesary anyway. Why and how
: frequently would I want to generate my config files programmatically?

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

Ivan
-- 
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form