Re: [boost] [Boost Review] Property Tree Library

From: Andy Little (andy_at_[hidden])
Date: 2006-04-20 14:55:20

"Marcin Kalicinski" wrote
>> The major use I thought of is a scene graph. This typically consists of a
>> large number of nodes ( Can be many Mb file) many containing structures of
>> points and transforms. I suspect its cheaper to keep these in memory in their
>> binary format rather than as strings.
>
> What you need to store a scene graph is a generic tree container, not ptree.
> Property tree is for storing properties. Anyway, if you want you can consider
> customizing data type to be some sort of Object *, but I don't know if this is
> going to take you very far.

AFAICS the current ptree could be a refinement of a a generic tree container,
however the current design of ptree is not so defined and its probably not going
to be possible to 'reverse engineer' genericity from the current design. One
example.. ptree doesnt distinguish the concepts of a branch and a leaf. It is
possible to imagine an alternative design in which a branch can be iterated over
whereas a leaf cannot, and the 'data' in a branch is a container of nodes
whereas the data in a leaf is not. Did you consider a generic tree design? If so
why did you reject it in favour of this one?

>> Whatever...  it would be interesting to see the rationale behind the design
>> decisions made within the documentation. I *think* that a trade off has been
>> made in favour of convenience and 'light weight' (I think it would not
>> perform
>> well on large files for example)
>
> Yes, being light-weight and easy to use it the main goal. I think this is said
> in the introduction part of the docs.

But it would be interesting to know why you have chosen this design over others.
That is not stated in the docs AFAICS. It would help when I wanted to use such a
library because it could help me to make a fast decisison as to whether it was
suitable. BTW the current 'Rationale' section looks more like a 'FAQ' section
FWIW.

>>>>Is it necessary to make key a string. Could it not also be (say) an integer
>>>>id?
>
> Library would need some sort of path parsing policy. I think that the only
> required function would be to separate head of the path from the tail (sort of
> Lisp-like behaviour). This is quite an interesting proposition, I consider it
> the most valuable addition to the library at the moment.

One option I envisage is to make a symbol table, where each new string token
encountered is given an integer id, and only the id's are stored in the tree.
The intent being to speed up key lookups. In this case a path to a node consists
of a linear container (e.g a vector) of integer ids. That might go against the
'light-weight' nature of the design though. In such a design a 'path' would  be
a concept, and a vector of integer ids might be a model of path as might a
string with separators. That would be a move towards a 'generic tree container'
approach. I guess though that whether that has potential, depends on your
answers to my questions above.

regards
Andy Little