Boost logo

Boost :

From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-05-22 17:39:49

> [...] Hope you don't mind if I add a couple of wishes/suggestions based on
> my recent usage:

You're very welcome! Suggestions based on real-life experience are the most
valuable. As you can see below I agree with most of your comments.

> - It should be possible pass the path separator char to the ctor, which
> then should be used as the default for all operations. This wish might be
> partly invalidated if/when you implement a path class.

One problem with it is that different nodes in the same hierarchy may end up
with different separators. Another problem is that every node will store a
copy of the separator, a waste of memory.

> - Preserve the possibility (in path class or wherever) to use a plain text
> string to specifiy a path. Please.

Yes, definitely. No worries :-) Judging by people's comments this has been
one of the biggest selling points of the library. Judging by my experience
with ptree, string paths are very useful. While path classes may provide
additional flexibility and performance where it is needed, string paths will
continue to provide simplicity and ease of use in a majority of real life
cases. How exactly this will be implemented is another issue.

> - Add a 'name()/full_name()' method to the interface; the name() method
> would return the current tree 'leaf' name and the full_name() returns the
> complete path from the root.

If done, this should return a path object which could optionally be turned
into a string if needed. But it is dependent on having parent data member.

> - Add 'parent()' method.

The reason why there is no parent() is that originally ptree held children
by pointers, not by values. This allowed, among other things, storing a
single child in many parents. Obviously, there was no good way to implement
parent() then, so it wasn't there. I dropped the pointers long time ago and
replaced them with values, because they were causing too much trouble and
some of the advantages they provided could be simulated another way. Now
that the tree only has one parent, parent() can be done easily. At the
moment I don't see any reason it should not be done.

> - Add support for relative paths; e.g. ptree::get("../sibling/arg")

Yes, if parent() is implemented, paths must support some sort of

> - I'm personally not found of e.g. operator[] acting the way as the
> std::map subscription operator.

I've done an experiment with operator [] recently. John Maddock presented
it quite nicely, proxy objects for nonexisting nodes, templated conversion
operators, etc., so I didn't have to do much thinking. It is very clever and
works, at least as far as I implemented it. But after the experiment, I
think it is actually _too_ clever. In case of ptree, I believe operator []
based interface is inferior to named functions. The reason is readability.
There are too many operations one can do on a node to cram them all into a
single-parameter operator. From my experiment, it looked more like an
exercise in C++ aerobatics, than a robust solution. Concluding, it has its
virtues, and I don't shelve it yet, but I must try something else first.


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