"Jeff Flinn" <TriumphSprint2000@hotmail.com> wrote in message news:e27qih$65r$1@sea.gmane.org... : Ivan Vecerina wrote: : > "Sebastian Redl" <sebastian.redl@getdesigned.at> wrote in message : > news:44463E63.6030703@getdesigned.at... : >> Marcin Kalicinski wrote: : >> : >>> Agreed. I thought about it before, and came to a conclusion that : >>> the best way to implement it is to use preprocessor constant to : >>> allow user specify default separator, e.g. : >>> BOOST_PROPERTY_TREE_SEPARATOR. : >>> : >>> : >> I disagree. I think this should be a runtime per-tree setting, not : >> something set at compile time. I also think it would be quite : >> trivial to do. : > : > Why do you care to have this as a per-tree setting ??? : > : > So now, say that someone writes a library function to read a ptree : > into a struct EmployeeInfo. Unless this function explicitly : > specifies the separator at every call, it will fail if you pass : > it a tree that is configured to use a different separator ? : > : > I'd much rather have a universal default ( . or / ), guaranteed, : > that I can use in all my "item paths". : > And maybe, if there is a reason to think that it will be useful, : > the ability to specify a custom separator for a call. But : > what is the point? : : What if the keys contain '.' or '/'? Then the function that uses such a key can explicitly specify a different separator, or use a different accessor function. One could also choose to provide an escaping mechanism within the path. But in the first place, ptree will never be able to open just any XML/whatever file - users of it can also adapt. Do you need to have built-in support for every corner case ? But the key point is: the function that uses a path string also knows which separator it intended to use in its notation. Storing the separator as a property of the tree goes against encapsulation. I would just pick a default separator. I don't care which choice is made, but '/' makes sense. Also implement path-access as non-member functions, so users are free to choose an path-specification approach if desired. And how about supporting array indexing in the path syntax ? Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form