Re: [boost] [Boost Review] Property Tree Library

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2006-04-24 08:55:43

Marcin Kalicinski wrote:
>> My vote on the current property_tree submission is NO. I think it
>> could be re-submitted in the future given a clear rationale
>> accurately stating: - it's intended use
>> - a comparison with similar libraries (have you looked at McObject's
>> ExtremeDb as one example)
>> - why/why not it's not based on boost.graph libray as a
>> Directed-Acyclic-Graph
>
> I believe this rather belongs to a domain of implementation details.
> What difference would there be for the users? I have a clear vision
> of ptree, and this is std container + extra member functions to make
> access a snap. I would not like to expose any boost.graph interface 
> anyway.

My point is that these reasons should have been stated in the rationale 
section of the documentation. What if I'd like to use BGL's bfs or dfs on 
the tree? Sounds like useful functionality to me, without reinventing the 
wheel.

>> - why would I not just use map< vector<string>, data > along with
>> upper/lower bound
>
> Hmm. I think I have an answer below:
>
> #include <map>
> #include <string>
> #include <vector>
> #include <sstream>
>
> // I want to extract an int from some config file
> int i;
>
> // That's what I've got to do:
>
> typedef std::map< std::vector<std::string>, std::string > Container;
> Container container;
> read_xml(..., container);  // Note this must be defined somewhere
> anyway std::vector<std::string> path;
> path.push_back("some");
> path.push_back("arbitrarily");
> path.push_back("long");
> path.push_back("path");
> Container::const_iterator it = container.find(path); // A very
> inefficient lookup
> if (it != container.end())
> {
>    std::ostringstream out_stream;
>    out_stream << it->second;
>    std::istringstream in_stream(out_stream.str());
>    in_stream >> i;    // Finally got it!
> }
> else
>  throw ...
>
> Not a pretty sight, is it? I'd rather download TinyXML. Note that it
> already assumes there are parsers implemented somewhere else, which
> create that monstrous map. The map solution also does not let you
> manipulate the hierarchy in memory - map is a linear structure even
> though it is internally implemented as a tree.

Again these issues should have been stated in the rationale section. And if 
the above used(the current CVS version) of boost::filesystem::path and/or 
the boost::assign, many of your objections could be alleviated. Which also 
brings up a possible solution using boost::spirit::symbol, which would have 
the benefits of a ternarys state tree.

> I believe any attempt to make the above shorter and more manageable
> leads just towards implementing another version of property_tree.

With a different set of abilities/limitations that the reviewers could 
compare.

Jeff Flinn