PropertyTree's XML parsers survey

From: Sebastian Redl
Hi,
PropertyTree currently has 5 (five!) different xml readers using 4 different parsers. I don't want to maintain them all. Looking at the open tickets for PT shows that most bugs occur in the various xml readers, and there's no point in having more than one.
I just wonder which one to keep. To those who use PropertyTree's XML format, which parser do you use? Do you have any experience with the pros and cons of the various parsers?
All feedback is highly appreciated. I had some experience with RapidXml managing the settings of my not a long time ago. Pro: - the API interfaces are STL-like, easy to use - header only Con: - ANSI only in practice - buggy in supporting wstring, and UNICODE. I ended up implementing my own version supporting UTF-16LE for Windows only based on RapidXml V1.11.
The most wanted XML parser/writer feature for me is the support of wide-char(UTF16) version of UNICODE, rather than UTF8. It seems no light-weight XML library does it well.

The serialization library has been using the spirit library for parsing XML for years. This is for both utf-8 and wide characters Robert Ramey Tan, Tom (Shanghai) wrote: >> From: Sebastian Redl>> >> Hi, >> >> PropertyTree currently has 5 (five!) different xml readers using 4 >> different parsers. I don't want to maintain them all. Looking at the >> open tickets for PT shows that most bugs occur in the various xml >> readers, and there's no point in having more than one. >> >> I just wonder which one to keep. To those who use PropertyTree's XML >> format, which parser do you use? Do you have any experience with the >> pros and cons of the various parsers? >> >> All feedback is highly appreciated. > I had some experience with RapidXml managing the settings of my not a > long time ago. > Pro: > - the API interfaces are STL-like, easy to use > - header only > Con: > - ANSI only in practice > - buggy in supporting wstring, and UNICODE. I ended up > implementing my own version supporting UTF-16LE for Windows only based > on RapidXml V1.11. > > The most wanted XML parser/writer feature for me is the support of > wide-char(UTF16) version of UNICODE, rather than UTF8. It seems no > light-weight XML library does it well.
participants (2)
-
Robert Ramey
-
Tan, Tom (Shanghai)