Re: [boost] [Boost Review] Property Tree Library
Marcin wrote
I think I understand your point, although you did not state it directly. (Please correct me if I'm wrong) you believe basic_ptree class has some value, and meets boost quality standard. On the other hand you think that parsers that accompany it do not.
However, I'm also sure you are aware of the fact that without _any_
I dont have a strong opinion one way another about the parsers meeting or not meeting boost standards. I just want to make shur that they get reviewed and let the boost members voice there opinions about them. parsers
the library is quite useless. It might still have some obscure uses, but at least 90% of it is gone.
I'm not aware of this. Please explain why the "property container" is useless without a parser. This is the critcal reason why I have issues with this library in its present form. Why is "property container" different from other containers such as vector or map in this regard.
Therefore I can only agree to your proposition if at least _one_ parser is included with the library. Which one is another issue, but I believe it should be XML.
That may be accaptable. However, its the XML parser that is my main concern. That would be the one that I would save for a later review.
Also please note that while at the moment some parsers may look ugly, it is the implementation that is ugly, not the interface. And implementation can
be safely improved while the library is already in boost.
Noted. Tom Brinkman Boost Review Wizard
However, I'm also sure you are aware of the fact that without _any_ parsers the library is quite useless. It might still have some obscure uses, but at least 90% of it is gone.
I'm not aware of this. Please explain why the "property container" is useless without a parser. This is the critcal reason why I have issues with this library in its present form. Why is "property container" different from other containers such as vector or map in this regard.
Comparison with vector or another std container is a bad idea. property_tree is not usable as a container alone. For that you should rather use multi_index, as Gennadiy said many times - it would be more flexible, and faster as well. multi_index does not have get/put etc. interface, but if you populated the tree manually, you anyway have another way of accessing (properly typed) data, so get/put is not so important. Empty property tree is useless. To populate it you need either to manually insert data, or use a function which does that in an organized way, like one of the parsers. While manually inserting data is common (in my experience with the library), it is only done to later save it to a file. Without parsers this becomes impossible. Briefly, the strong point of the library is that it can represent data coming from different sources in an uniform way. You propose to cut that sources off completely, at least for a period of time. How about adding the following question that each reviewer should try to answer: Which of the existing parsers (XML, JSON, INI, Registry, cmdline, INFO) are mature enough to be included with the library now? Which should be improved, and undergo another review later? When enough answers are gathered, the review manager will be able to make an educated decision what to cut. Best regards, Marcin
participants (2)
-
Marcin Kalicinski -
Tom Brinkman