[property tree review] No seperator additions
It would be nice if there were 'no seperator' variants of the the get and out methods that took an array of strings, 'const tr1_or_boost::array<key_type,T>& path', instead of 'const key_type &path'. Having this makes the api a little more object oriented instead of paths needing parsing. It can make it easier to use in more advanced scenarios as the user need not know what the seperator is and what to do if string data has that seperator. I am not saying any of the existing functions are wrong. Frankly, I like them. However, the users of this api could benefit by these minor additions. On a side note the link to some of the examples such a changing the value type seems to be broken. I would definitely like to see what I can do with the ptree_trait to allow using boost::any or the optimized cdiggins::any instead of string. // No separator template<class Type> Type get(const tr1_or_boost::array<key_type,T>& path, const std::locale &loc = std::locale()) const; // No separator template<class Type> Type get(const tr1_or_boost::array<key_type,T>& path, const Type &default_value, const std::locale &loc = std::locale()) const; template<class CharType> std::basic_string<CharType> get(const tr1_or_boost::array<key_type,T>& path, const CharType *default_value, const std::locale &loc = std::locale()) const; // No separator template<class Type> boost::optional<Type> get_optional(const tr1_or_boost::array<key_type,T>& path, const std::locale &loc = std::locale()) const; // No separator template<class Type> basic_ptree &put(const tr1_or_boost::array<key_type,T>& path, const Type &value, bool do_not_replace = false, const std::locale &loc = std::locale());
Jarrad Waterloo <jwaterloo <at> dynamicquest.com> writes:
// No separator
template<class Type> Type get(const tr1_or_boost::array<key_type,T>& path, const Type &default_value, const std::locale &loc = std::locale()) const;
template<class CharType> std::basic_string<CharType> get(const tr1_or_boost::array<key_type,T>& path, const CharType *default_value, const std::locale &loc = std::locale()) const;
Why not template <class IteratorT> string_type get(IteratorT beg, IteratorT end); template <class IteratorT> string_type get(IteratorT beg, IteratorT end, const string_type::value_type* default_value); I don't really se the need for the converting get functions. Why is pt.get<double>(path) better than lexical_cast<double>(pt.get(path)). (or string_to or atof)
// No separator
template<class Type> basic_ptree &put(const tr1_or_boost::array<key_type,T>& path, const Type &value, bool do_not_replace = false, const std::locale &loc = std::locale());
Same here: why not pt.put(path.begin(), path.end(), lexical_cast<string>(val))
I don't really se the need for the converting get functions.
Why is pt.get<double>(path) better than lexical_cast<double>(pt.get(path)). (or string_to or atof)
There will be problems with non-throwing failure handling. Users will be forced to write something like that: double d; try { d = boost::lexical_cast<double>(pt.get(path, default_value)); } catch (boost::bad_lexical_cast &) { d = default_value; } instead of just: double d = pt.get(path, default_value); Even if failure handling is not an issue, explicit use of lexical_cast forces uses to do one extra include, and writing: boost::lexical_cast<int>(pt.get("path")); // #1 instead of: pt.get<int>(path); // #2 Which in my opinion is much less readable. 95% of uses will do type conversion anyway (that comes from my personal experience with the library), so forcing users to write #1 instead of #2 in all these cases will do no good. Also, user can use lexical_cast now if he really wants to: int n = boost::lexical_cast<int>(pt.get<std::string>("path")); Best regards, Marcin
It would be nice if there were 'no seperator' variants of the the get and out methods that took an array of strings, 'const tr1_or_boost::array<key_type,T>& path', instead of 'const key_type &path'.
That falls into the category of path object, proposed by many people. For example: pt.get(path("a") / "very" / "long" / "path") Path object can then be made to accept iterators: array<const char *> src = {"a", "very", "long", "path"}; pt.get(path(src.begin(), src.end())) Some sort of path object will most probably replace current path parsing in the next revision.
On a side note the link to some of the examples such a changing the value type seems to be broken.
This link works for me: http://kaalus.atspace.com/ptree/examples/custom_data_type.cpp The example uses boost::any as data type and boost::any_cast to convert types. Best regards, Marcin
participants (3)
-
Jarrad Waterloo -
Marcin Kalicinski -
Martin Adrian