Property tree rev.5
Property tree library revision 5 (review version) is now in the boost vault. Documentation can be viewed online at http://kaalus.atspace.com/ptree Major changes since revision 4: - basic_ptree no longer templated on character type, now templated on key type instead - get_b functions removed - get_o functions renamed get_optional - get_d functions renamed get, (resolution with throwing get through overloading) - enhancements to cmdline_parser - added more regression tests - updated docs and examples Marcin
"Marcin Kalicinski" <kalita@poczta.onet.pl> writes:
Property tree library revision 5 (review version) is now in the boost vault. Documentation can be viewed online at http://kaalus.atspace.com/ptree
What is the rationale for using the word "property" here? Why is this data structure not a more generic tree? It seems as though forcing the data on a tree node to be a specialization of basic_string is needlessly limiting. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave <at> boost-consulting.com> writes:
"Marcin Kalicinski" <kalita <at> poczta.onet.pl> writes:
Property tree library revision 5 (review version) is now in the boost vault. Documentation can be viewed online at http://kaalus.atspace.com/ptree
What is the rationale for using the word "property" here?
Why is this data structure not a more generic tree? It seems as though forcing the data on a tree node to be a specialization of basic_string is needlessly limiting.
That reminds me of Dave Handley's implementation of a composite pattern library, see http://aspn.activestate.com/ASPN/Mail/Message/2301865 Maybe it would be harder to implement all the file read/write functions with this one, though. -- Klaus Nowikow
What boost needs is a generic tree container library that can include as utilities some of the functionality in the proposed property-tree library. Some references: * Tree Container Library http://www.codeproject.com/library/tree_container.asp The author plans to submit it to boost . This should combine with the current proposed library * tree.hh: an STL-like C++ tree class (GNU) http://www.aei.mpg.de/~peekas/tree/ This library is well regarded and widely used in many GNU projects If some of the STL gurus can compare both libraries we could contact the author to encourage it to submit it to boost or just change the license. A key functionality for the new library is being able to load an XML file in memory and provide an easy-to-use DOM-like interface. Regards Jose On 4/11/06, Klaus Nowikow <nowikow@decomsys.com> wrote:
David Abrahams <dave <at> boost-consulting.com> writes:
"Marcin Kalicinski" <kalita <at> poczta.onet.pl> writes:
Property tree library revision 5 (review version) is now in the boost vault. Documentation can be viewed online at http://kaalus.atspace.com/ptree
What is the rationale for using the word "property" here?
Why is this data structure not a more generic tree? It seems as though forcing the data on a tree node to be a specialization of basic_string is needlessly limiting.
That reminds me of Dave Handley's implementation of a composite pattern library, see http://aspn.activestate.com/ASPN/Mail/Message/2301865
Maybe it would be harder to implement all the file read/write functions with this one, though.
-- Klaus Nowikow
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 4/11/06, David Abrahams <dave@boost-consulting.com> wrote:
What is the rationale for using the word "property" here?
Why is this data structure not a more generic tree? It seems as though forcing the data on a tree node to be a specialization of basic_string is needlessly limiting.
Perhaps the use of std::string is needlessly limiting, but what makes the property_tree a little bit different than a generic tree container is the concept that child nodes are associated with a key, and there are convenience methods provided for finding nodes by their "path" in the tree. The same effect could perhaps be accomlished using (hypothetically) a generic_tree<std::pair<std::string, std::string> >, but this would need to in turn be wrapped in another interface to achieve the same ease-of-use. -- Caleb Epstein caleb dot epstein at gmail dot com
Why is this data structure not a more generic tree? It seems as though forcing the data on a tree node to be a specialization of basic_string is needlessly limiting.
Data doesn't have to be a basic_string. You can change it to anything else by supplying different traits to basic_ptree class template. There is an example showing how to use tree with boost::any instead of the string. On the other hand, please note that this library is not a generic tree container - it is intended to be used as a DOM that supports reading/writing multiple data formats out of the box, and gives easy and idiomatic access to the data, without writing miles of supporting code.
What is the rationale for using the word "property" here?
The class is a map from keys to properties (data). I think that idea for the name originally came from java.util.Properties class in Java, which has similar purpose but is flat, not tree-like. Best regards, Marcin
Marcin Kalicinski wrote:
Property tree library revision 5 (review version) is now in the boost vault. Documentation can be viewed online at http://kaalus.atspace.com/ptree
Hi Marcin, I went through the documentation and used your property tree library to implement a configuraton class which loads configuration data from a file. Here are some notes: * When going through the five minute tutorial in the documentation I missed what the header file is actually called I have to include. It would be good to start the tutorial with #include <boost/property_tree/ptree.hpp>. * I haven't seen previous library versions but did you consider of adding another constructor explicit basic_ptree(Ch separator)? This would allow to change the separator ptree-wide. * It should be emphasized in the documentation that eg. when you parse a XML file and expect keys to be case-insensitive you must use iptree and not ptree. The XML parser by itself doesn't do anything but copying keys and values to the property tree. After all I appreciated to implement the (fairly small) configuration class in one hour instead of using full-featured XML parsers like MS XML and Expat. Property tree could be or use a generic tree class but what makes it handy are the read/write functions to populate and serialize a tree easily. In the longterm however a generic tree and the serializiation library might probably do the same what property tree does today. The advantage of property tree is however that it can be understood and used quickly. Boris
On Tue, 11 Apr 2006 00:04:06 +0100, Marcin Kalicinski wrote
Property tree library revision 5 (review version) is now in the boost vault. Documentation can be viewed online at http://kaalus.atspace.com/ptree
I took a quick look this morning -- it's very slick. The interface is clean and obvious -- I especially like the get_optional. The focus on supporting multiple external formats while maintaining a common internal interface is a very smart design decision. I'll definately be using this class :-) A couple things I discovered: - Couldn't get find to work - Docs Need an example of using the iterators (no example either) - If you read an ini file with comments and then write it back they are lost - Indenting and other attributes of the ini file are also lost. Only serious thing is I can't seem to get 'find' to work. ptree pt; read_ini("test.ini", pt); ptree::const_iterator ci = pt.find("value2"); if (ci != pt.end()) { std::cout << ci->second.data() << std::endl; } //test.ini [User Data] ; This is a comment value1 = v1 value2 = v2 date = 2006-Apr-18 I tried various keys in the find -- all returned null iterator. One really interesting extension for this would be a combination with Boost.Filesystem for reading file properties. You could use filesystem to populate the tree and then you'd have a really handy data structure for accessing file properties. Jeff
"Marcin Kalicinski" <wrote
Property tree library revision 5 (review version) is now in the boost vault. Documentation can be viewed online at http://kaalus.atspace.com/ptree
I dont understand the char_type member typedef of the traits class. The functions that use it all seeem to be free functions which could change from e.g template<class Ptree> void read_xml(std::basic_istream<typename Ptree::char_type> &stream, Ptree &pt, int flags = 0); to template<class Ptree, class Char> void read_xml(std::basic_istream<Char> &stream, Ptree &pt,int flags = 0); without problems. That would remove one level of coupling wouldnt it? regards Andy little
participants (8)
-
Andy Little -
Boris -
Caleb Epstein -
David Abrahams -
Jeff Garland -
Jose -
Klaus Nowikow -
Marcin Kalicinski