"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote in message news:e287in$lsr$1@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