Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-04-22 08:00:22

Marcin Kalicinski wrote:

Marcin, consider leaving the attribution intact, as I believe Dave has
already requested.

>> [...] that's the main problem with this submission. Instead of
>> clearly specified problem domain and design that address issue in
>> this domain, you present some mixture of half-good components each
>> with unclear advantages over existing dedicated solution in each
>> respective area. [...] We do need good tree storage. We do need better
>> runtime parameters
>> support library (IMO). We already have quite powerful solution for
>> permanent storage support, but we could use more archive formats for
>> it. What you propose is none of it.
> I'm sure you will agree that ptree is different from serialization.
> If you don't agree, read some of quite interesting posts by Ivan
> Vecerina. The main difference is that serialization lib is _only_
> about translation of some C++ structures to/from a string of bytes.

This is not entirely correct, even though Robert himself states so. The
serialization library has two separate parts: the first part translates a
C++ structure into a sequence of archive calls, the second part (the
archive) translates this sequence to either a string of bytes or something
else (a property tree, for example.)

The problem (in this context) with the serialization library is that its
first part inserts semi-opaque metadata into the stream which leads to the
output being not particularly well suited for human-readable and editable
configuration files.

Anyway, as I'm already in the thread...

In my opinion, the property tree library is at or above the average Boost
quality and should be accepted. It is obvious (at least from a quick reading
of the documentation) that it has a reasonably clear purpose and fulfills
this purpose pretty well.

There is a significant overlap with other existing and future (string_to)
Boost components, but the overlap is inherent in the design and cannot be
eliminated without making the library something else entirely.

It is evident that the library is string-based at its heart and the
parameterization on arbitrary key or value types is not yet a first-class
citizen. It is likely that the interface needs to evolve a bit in this area.
As an example, tree structures that hold intrusive_ptr<element> and can be
indexed by path are very useful. On the other hand, we should evaluate
whether a non-string key type works at all, since most interesting library
features don't seem to be available, it degenerates into the simple struct
shown at the start of the tutorial.

I very much do not like the 'traits' policy parameter (which is not a traits
class at all, even though basic_string says so.) Do not deceive the users
that you have a single axis of parameterization when in fact you have six,
some of them redundant, some of them more useful than others. basic_ptree
should be templatized on key, data, ordering, inserter and extractor, not
necessarily in that order. The default arguments should be clearly
documented and useful outside of the library context. It should be possible
to eliminate char_type, but I'm not 100% positive about it.

One easy way to eliminate the distinct separator methods would be to make
the path syntax always start with a separator. If we really want a
non-string key type, one option I see is to use vector<key_type> as a path.

It might be useful to make the library take filesystem paths, getting the
operator/ for free.

The INI parser could probably support more than one level by using
l1.l2.l3.l4 as key (with an appropriate escaping scheme for the real dot.)

Boost list run by bdawes at, gregod at, cpdaniel at, john at