Boost logo

Boost :

From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-24 05:32:54

"Boris" <boriss_at_[hidden]> wrote in message
: Gennadiy Rozental wrote:
: > [...] Option 3:
: > Generic facility to manipulate hieratical data with permanent storage
: > support.
: > ==========================
: >
: > My main objection in this domain is that author decided that his
: > particular data structure would be good enough for all usages. The
: > word "particular" is main offender here. I don't believe any
: > "particular" data structure would be good enough. Some novice users
: > use simple structure with class
: > Leaf and class Brunch. Some prefer generic tree one. Some need
: > compile time polymorphism only. Some could use runtime one. Some
: > Would use boost::variant as value.
: > IMO save/load side of the library like this would need to be made to
: > work with any data structure satisfying some concept. The same
: > applies to access methods (This is the reason why you need to switch
: > to free function based interfaces)
: I agree. That's why I asked in another thread if the access methods are
: loosely or tightly coupled with property_tree. Marcin himself wrote in
: another message that using property_tree "is a matter of internal
: implementation". Adding some more flexibility here would be nice and
: to be possible.

I agree as well.

As much as I initially disliked the ptree data structure (I am used to
a polymorphic record/array/leaf node), I think that it has the true
merit of providing a reasonable common in-memory representation for
a variety of back-ends formats (XML, JSON, MSWin registry, Init, ...)
I would have liked to see a class that enforces a longer list of
invariants (e.g. enforcing only pure array//record//leaf nodes),
but this would restrict the range of the supported formats.

I think that by introducing this library into boost, we provide a
platform for further developments, with a good potential for
synergy with po & s11n.

However, I cannot agree to see this common in-memory representation
burdened and crippled by what is currently a too narrow and too
limited value conversion interface. So my vote is to keep this value
conversion & path handling separate: either in a distinct wrapper
(path parsing & value conversion) class, or as free functions.

If this requires delaying the adoption of ptree, or adopting it
without a value conversion interface, then so be it.
But as a minimal change least-effort option, moving the member
functions out into a dedicated namespace would be acceptable to me.

Of course this is just my vote, with all due respect to
Marcin's excellent work and valuable contribution.


-- <- email contact form

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