Re: [boost] Proposal: property_tree(property_tree.zip uploaded to vault)

From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2005-11-11 05:52:15

> 1. The get and put functions use operator<< and operator>> but I don't see
> anyway of specifying locale. I would prefer some kind of root imbue
function
> but since the root isn't special I assume the get/put functions need a
locale
> argument.

Currently they just use global locale so it is possible to use a different
one by changing it. But obviously it is not very convenient, especially in
multithreading environment. Some time ago I was trying various ways of
specifying locale, and I think the best way would be indeed having an extra
parameter to get/put functions. But I'm not sure if it should be just a
locale - some people might also want to change default formatting flags of
the stream, such as hex or boolalpha. Maybe it would be a better idea to
allow passing not a locale, but a whole stream to be used for conversion?

> 2. Would it be possible to change the template arguments to container and
less
> predicate? Then you can use any string type and easliy get case
insensitivity
> with string_algo iless.

I think it would be easier to get case insensitivity by just providing
another version of ptree_traits, than allowing use of other string classes.

> 3. Why pointers instead of references?

I use pointers in many places so that NULL can be used to specify default
behaviour. For example:

bool exists = pt.get_b("a", NULL);    // Checks for presence of "a"

or

ptree *pt = get_child_d("a", NULL, NULL);    // If "a" is not found returns
NULL

With references this would be impossible.

> 4. I assume paths are constants most of the time. A (w_)char or range
overload
> would avoid a string copy (and memory allocation) for each operation.

That's a valid point, but I'm not sure if the gain is big enough to justify
addition of another set of overloads. Searching the path is not a simple
operation, and making a single allocation and a copy is not a huge overhead.
On some implementations short paths will not cause allocation anyway.

regards,
Marcin