"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote in message news:e2asoc$2mn$1@sea.gmane.org... : > There is a profusion of applications that use xml, JSON, or a similar : > format for data storage. In all these applications, being able to : > dynamically manipulate an in-memory representation of the data : > structure is a very common need. : > boost::serialize goes straight from C++ object to stream, and there : > is no opportunity to manipulate the stored data in-memory (let me : > be corrected if I am wrong). : : See my other post. What do you mean by manipulate the data? : Care to give an example? - extract some field values and inject them into an HTML document template (e.g. for a report-generator) - manipulate the contents of an XML/configuration file that contains classes for which I have no C++ class defined. But also: - maybe I want to handle the same kind of dynamic data structures that all scripting languages have available (e.g. represent 'instances' of a dynamic class in a portable way). - maybe I want better forward & backward portability of my storage file format than boost::serialize allows (manually checking for the existence of certain fields is more flexible). - maybe boost::serialize is too rigid when it comes to reading a file that has been edited by users - maybe boost::serialize is too complex and intimidating It's not like boost::serialize currently dominates the world of persistent storage. Obviously many developers are not happy with it and use other kinds of solutions (JSON, XML, etc). That is a fact. : > xml, JSON, the Windows registry, some uses of command-line parameters, etc : > have a lot of common. And ptree seeks to provide a common in-memory : > representation for all these formats. I see a real value it in. : : Runtime parameters support facility require a lot more then just common : representation. It needs to support at least following features: I said *some* uses of command-line parameters. Your demands are higher, without doubt. Many standard libraries have limitations that make them unacceptable to some users. A library exists for parsing CLA, but its scope is extremely narrow and specific. : > How would you look at ptree being a possible target format (Archive) : > for boost::serialize ? : : I am not sure I understand: how PT could be an Archive? Archive if I am not : mistaken is the model of permanent storage. PT is the model of in-memory : storage. ... which is why PT is very complementary. My point is: if there is such a strong overlap between the data structure of boost::serialize and PT, then probably PT could use the (XML) serialization archive protocol to read/write XML files. A common back-end protocol would allow every new format support (JSON, INFO, etc) to be leveraged by both libraries. At the same time, by providing a serialization archive that constructs an in-memory PT, the PT library would leverage the assets of boost::serialize, for example to facilitate the conversion of a struct to a ptree. Where you see overlap and redundancy, I see complementarity and opportunity for synergy. Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form