[...] So let me give it another try to convey my point clearly: I don't see any reason to discuss library interfaces and even more implementation without clearly stated problem domain.
I admit that the documentation fails to specify the problem domain. The tutorial presents the library as a config-file reader and stops there. Hence the original discussion, whether it overlaps 1:1 with program options or serialization, etc. Its my fault, I will try to correct this unpleasant state of matters.
How could you tell whether one interface/implementation is better than another without understanding how it's planned to be used?
*** The goals *** =========================== 1. Allow efficient and intuitive manipulation of hierarchical, human-readable data structures in memory. Like a DOM, but with as simple to use interface as possible! The interface must leverage C++ strenghts (type safety, templates to automatically convert types), and maybe more importanly C++ idioms (ptree = std container, iterators, algorithms). Tradeoffs: no stress on performance, no following of W3C DOM standard. 2. A facility to load and save most popular, human readable data file formats (and present them in the form of above structure). Tradeoffs: no stress on supporting each format in its entirety. Omit less used and more complicated parts of the file formats. Get it working for 80% of cases now, rather than for 100% never. I believe the library meets the above goals reasonably well at the moment. With all the proposals I got I think I can make it do it even better. *** Problem domain *** ========================== First of all, I don't think author of almost any library can definitely say: this library will be used to do A and B, but not C. Loading human readable data, allowing its manipulation in memory, and saving it back again. This can be used for a plethora of things, and nobody cannot possibly be expected to enumerate all of them. I will try to present a sample: 1. Loading and saving program data. For example in a GUI editor for something that is persisted in an XML format with externally defined layout. Cannot use boost::serialization, because it isn't format-flexible. You get your XML out of it if you really want, but only in vanilla flavour. No saying what should go where. 2. Serialization (in primitive form, but supports human-editable formats). I say "primitive", because I'm now an initiate - I used boost::serialization in some of my projects. Before I did that, I would say ptree offered "adequate" serialization facilities. 3. Loading of program options, aka program_options overlap 4. Passing of data between parts of the same program. This is a little more tricky than the others. For example, consider the parts to be (1) a fancy menu system for a video game, and (2) the game itself. Menus build a ptree and pass it to the game. Why? You can save the generated ptree and reuse it later without starting the menus. You can hand-edit it and configure the game wihout having the menus at all. This is extremely handy if menus and game are developed separately. You may find yourself in a situation where you are working on the game, but menus do not exist yet in an usable state. You do not need to "fake" a menu system to test your game. You just handcraft the ptrees. (i.e write some text files in your fav format). 5. A use that surfaced lately: target for boost::serialization (ptree_archive). Why? Can save archives to all formats supported by ptree, effectively extending boost::serialization for free. And (speculating), maybe it can be used to automatically reorganize XML layout, so that comments on boost::serialization in #1 no longer apply. 6. Translation from one format to another. I'm sure others could extend that list. Best regards, Marcin