"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