Re: [boost] [Boost Review] Doreallyproperty_treeandprogram_optionsoverlap?

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-04-21 15:50:28

"Ivan Vecerina" <ivec_at_[hidden]> wrote in message 
news:e2b3d4$rgt$1_at_sea.gmane.org...
> "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.

There is quite a veriety of in-memory data structures already exist that 
would allow one to manipulate data in more convinient/effitient and relyable 
way.

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

So? What's the problem? Use tree with strings in nodes.

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

Maybe you need to make up to my mind on what you need? If it's permanent 
storage for configuration edited at runtime, why do you need to edit it 
manually?
In any case all of  the problems above could be solved with PT.

> It's not like boost::serialize currently dominates the world
> of persistent storage.

So? I see a potencial for it to become a standard like iostreams now.

> Obviously many developers are not
> happy with it and use other kinds of solutions (JSON, XML, etc).
> That is a fact.

Is it?

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

But Why would I need another data structure? How is it better than tree or 
multiindex?

> My point is: if there is such a strong overlap between the data
> structure of boost::serialize and PT,

There is none. boost::serialize doesn't deal in data structure domain.

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

All of the above *could* be done. I still do not see why it *should*? What 
are the advatages of PT over other data structures.

Gennadiy