From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2006-04-19 11:59:22
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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk