On 9/8/06, Robert Ramey <ramey@rrsd.com> wrote:
If you've looked at serialization of xml you'll see that it uses spirit and an xml grammer derived from a complete one included in the spirit library. If you really don't want to re-invent the wheel, they why not just use the same approach? The spirit library contains a very complete XML grammer already. I don't recall this even having been considered - much less rejected. Creating XML is easy. Handling issues of code conversion (e.g. from locale specific code to UTF-8 or UTF-16) is easily handled with i/o stream facets - some of which are also already available. It is also already "Boost Friendly" and works with all boost platforms. It also does most of the heavy lifting at compile time - very much in line with other boost tools. I can't understand why any other approach would be attractive for users of other boost libraries. To me the whole idea is "re-inventing the wheel"
The only argument I'd have against it is that libraries like expat and libxml2 are hugely optimized, and I have found in the past that XML parsing can account for a significant percentage of runtime in some applications. Has anyone done any performance benchmarks on the spirit xml parser? In the past I've found that, past a certain level of complexity, spirit parsers are substantially slower than handcrafted alternatives, but that could simply be because I'm not an expert in writing "good" spirit parsers.