"Marcin Kalicinski" wrote:
* Optional MT safety may be added.
I would rather leave it at std::container style - no built-in safety.
Having get/set protected by mutext doesn't guarantee complete MT safety but it should be enough for application where the configuration is loaded, read (from one or more threads) and at the end saved. More complex scenarios would need user written wrapper.
* Preserving comments and whitespace in INI/JSON/INFO could be the /most/ important reason someone decides to use the library.
The more I think about it, the simpler it seems, and originally I thought it is a definite no-no, just look at my replies to Jeff Garland. Some suggested adding extra fields to the node, but this is not acceptable for me; if comments cannot be handled by the tree alone it's better if they are not handled at all. The way to do it is to add metadata (like <xmlattr> or "\values"), which describes comments and optionally location. Of course this will slow some of the parsers very significantly, so it should be optional. Metadata will be fully editable, but will not pollute normal data. I hope this is doable.
I won't talk about XML (do not use, not that much knowledge, doubts about its future). It is implementable for INIs (I did it) - these metadata would be loaded, hidden from user but saved. For JSON and INFO this likely applies as well. As comments and whitespace are metadata the application should not have any access to them. They should NOT be editable (by the application).
* Overloads for parsers to parse given memory block (e.g. mapped file, shared memory)
Maybe. But how about doing another library that presents arbitrary memory block in form of C++ stream? I think it would be usable in many other contexts as well, and in one of my projects definitely. Stringstream is flawed because it must copy the data first. Copying whole memory-mapped file is really a rubbish idea :-)
Hmm, possibly. Having parse(condt void* data, unsigned size, ptree&); is however the simples interface possible. The string type may be custom one, pointing into provided memory instead of using allocations of its own. The result would be something able to parse really large amount of data. /Pavel