Re: [boost] [Boost Review] Do reallyproperty_treeandprogram_optionsoverlap?

From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-21 13:05:48

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote in message 
news:e2asoc$2mn$1_at_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