Brent Arias wrote:

Regarding the write_xml routine used with the boost Property Tree, it evidently does not utilize the underlying RapidXML tool? Said differently, is it true Property Tree relies on RapidXML for the reading step, but not the writing step?

Correct.

I ask because I may be swapping Property Tree’s dependence on RapidXML, for a Unicode branch of pugiXML http://code.google.com/p/pugixml/source/browse/#svn/branches/unicode instead, so that I get free conversions to-and-from UTF-16/UTF-8. But if Property Tree does not use the underlying XML parser for the writing step, then I won’t get that free conversion when writing back to disk.

Correct. That said, if you have a wptree and imbue the output stream with a utf8 codecvt facet, you get UTF-8 XML.

As for the read_xml func, is it also true that “twice” the memory is needed, because RapidXML will load a document into a DOM, and then the Property Tree will allocate more memory to convert the DOM content into its own format?

Sort of. Note, though, that RapidXML is an in-place parser, i.e. all the string data of the nodes is represented by references into the original XML code. (This is also why some things, like entity expansion, are not really supported by RapidXML.) So you spend memory once for the input text, a bit of memory for the nodes of the DOM, and then a lot of memory on the property tree. I have a feeling though that cases where this memory is a concern may not be ideal use cases for proptree. At least that's not what I focus on for proptree. But of course libraries get used for purposes not originally intended by the author (or maintainer in my case) all the time. Sebastian