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.
Best regards,
Marcin