From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-21 13:05:48
"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote in message
: > 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
- 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,
: > 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
: > 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
: mistaken is the model of permanent storage. PT is the model of in-memory
... 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.
-- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk