Hi Pavel, Thank you for another review, it's probably 4th or even 5th, counting ones you did before the review started.
Temptation to extend the now simple API into giant does-it-all tool may result in something practically no one would dare to use.
Right. A lot of the people posting to this thread proposed at least one new major feature. If I added all of them (if I ever managed to), the library would sink under its own weight.
1. Examples, examples, examples.
Probably a very good idea. But I need to port docs to QuickBook first. Otherwise maintaining it is going to kill me.
Rename the library to "simple property tree" if people cannot stop requesting more.
He he he. I don't think it is going to stop them.
* basic_string should not be hardcoded. There are too many string implementations floating around.
It is now only "soft-coded" for the key type. By "soft-coded" I mean that some std::string interface is required (substr etc.), but key_type itself can be changed. Of course, this sort of partial solution is not sufficient. Adding more generic path/keys support is the now the most important change waiting in the queue.
* Optional MT safety may be added.
I would rather leave it at std::container style - no built-in safety.
* 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.
* The property tree itself may be serializable as it could be part of larger application state
Yes. This is probably very easy to do.
* Support for various Unicode encodings (frex reading UTF16 BE and converting the strings to ANSI, all transparently).
If I understand the problem correctly, this is a job for codecvt facet, it was designed to do it. Library only allows setting locale for all relevant operations.
* 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 :-)
* An user defined datatype (e.g. boost::any) attached to each node may be useful [...]
No problem now. Customize data_type. Thank you again, Marcin