From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-23 19:02:03
>[...] 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk