Sebastian Redl wrote:
Andy Little wrote:
...
Is it necessary to make key a string. Could it not also be (say) an integer id?
It's certainly possible in theory, and the key_type typedef in the traits should make it possible in practice too. From looking at the implementation, it appears, however, that the key type must provide the std::string interface. This makes sense, in a way, as the keys can be concatenated to directly access deep properties.
I haven't had a chance to look at the library yet, but I'd have thought there would be a corresponding path concept/class. The std::string in the interface sounds overly restrictive. Just as the string algorithm is not restricted to std::(w)string.
The question is whether making this more flexible, either by having the traits supply a conversion from string to key and do the lookup by tokenizing and converting each token, or by having the traits supply a type-specific concatenation operation, is worth the trouble. Using any key type but string makes most of the readers and writers useless: the existence of any XML where all element and attribute names are numbers is doubtful (and perhaps even forbidden, I'd have to check the specs).
Is property_tree then actually an XML library.
In addition, such an interface makes the implementation and the traits that much more complicated.
I'll try to take a more in depth look at the lib soon. Jeff Flinn