: I admit I must've misinterpret the problem domain you are trying to cover. : So now you are saying that your library should be used to implement : permanent data storage? But we already have a solution for that either. : Much better IMO in any sense (safety, convenience, automation etc). All in : all in between PO an Serialization library I do not see any place for this : submission.
Hi Gennadiy,
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?
: It's doesn't stand a comparison as runtime parameters support : facility even with PO library ( no conflict resolution, no formats : specification, no automatic/custom validation no async action assignment : etc). And it's doesn't stand a comparison as a permanent storage facility : with Serialization library (in most senses). Make no mistake these are two : different domains.
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: * Conflict resolution What if the same parameter is in multiple sources? * Parsers should be flexible t osupport variety of formats CLA parser in particular. * There should be an ability for validation/notification automation. I want to register a callbacks for particular parameters and validation rules. There are more, but my point is that this library doesn't address any of it. So it couldn't be considered as viable candidate for runtime parameters support Also such facility wouldn't require any kind of fast search - no need to complicate the design.
But I have a question for you, or for any advanced user/developer of boost serialize:
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. Gennadiy