From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-22 14:41:09
> 1) Find is under documented / doesn't work for me
> I tried various keys in the find including:
> ptree::const_iterator ci = pt.find("User Data.value2");
find() is a standard-container type function, it does not accept paths, only
single keys. Use get_child instead. This is excerpt from docs on find():
Finds direct child stored at specified key. If there is more than one child
with the same key, the first one is returned. Time complexity is O(log n).
Keys equivalence is tested with a predicate supplied as basic_ptree template
parameter. If child is not found, returns end(). Both const and non-const
versions are provided. To find non-direct children use get_child function.
I hope it states clearly enough it only finds direct children, and also
gives you a colored, underlined link to a function which works with paths
(get_child). Btw. all std-container functions work only on direct children.
Only extra functions get/put etc. recongnize paths. This is by design. As
far as I remember, it is nowhere directly said in docs, which definitely is
a nasty omission.
> 2) Iterators are underspecified
> It was totally unclear to me from the docs what the interface to
> iterators returned from the interface. I finally found a test or
> example and copied.
> std::cout << ci->second.data() << std::endl;
Maybe the problem is that it is understated that basic_ptree is a standard
container? All containers have value_type member that defines what is
stored, and ptree is no exception. You only have to look it up in reference.
Additionally there's whole section "Property tree as a container" which
talks, among other things, about value type stored in ptree. I'm open to
suggestions, please let me know what you think should be added and where to
make it more clear.
> 3) Write operations are not 'whitespace' and comment preserving
> To me this is a critical point not fulfilled by the library. Most
> real-world configuration files have comments. If the application needs
> to read/write the files it needs to maintain the comments as human
I'm afraid I must disagree with you. What is manipulated by property_tree is
data. Data in case of INI file are sections, keys and values. If you want
comments, you must use another format that explicitly has support for
comments. Ptree at the moment supports only one such format: XML.
That said, how would you imagine data about comments and layout should be
stored/manipulated? Should the library distinguish between tabs and spaces,
count lines between entries etc? Would it be possible to manipulate this
metadata on par with normal data? What would be use of that if you
deleted/added keys in runtime. For example:
Now you add "Grapefruit". How would you know you should add it after Lemon
and before Banana, because otherwise it would violate your comments? There's
a whole pandora box of problems. Should comments be attached to nodes? What
about comments in between nodes? What about whitespace, should it be
attached to nodes before it, or after it, or maybe split in half?
You must also remember we are now using INI files as example. This format
has really simple layout. What about JSON, where you can have multiple keys
in one line, and many more variations? I think preserving layout in presence
of additions/deletions or even node modifications is impractical. In case
there are no modifications, there is no need to save. Even if there was, you
could just store contents of the file along with the tree.
Please let me know if you have idea on how whitespace/layout/comments could
be preserved easily. If there is no such way I can only say this
functionality does not belong to this library. It's rather text editor job.
One solution to this problem that comes to my mind is to create another
parser, called e.g. meta_ini_parser, that would not only extract real data,
but everything. Every comment would have its own node. Every continuous
stream of whitespace would have its node as well. Actually this is quite
possible to do, but the tree that you got from it would not be extremely
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk