Re: [boost] Question about useful libraries

Subject: Re: [boost] Question about useful libraries
From: Sebastian Karlsson (sairony_at_[hidden])
Date: 2011-06-29 07:43:03

2011/6/29 Mathias Gaunard <mathias.gaunard_at_[hidden]>:
> On 06/28/2011 01:17 PM, Sebastian Karlsson wrote:
>>
>> Secondly an XML parser /
>> writer can be written to a very high quality using the libraries
>> already present in boost ( spirit&  iostreams comes to mind )
>
> A spirit-based XML parser doesn't seem that great.
>
> If using semantic actions, it would necessarily be SAX-like.
> If using attributes, it would be like the DOM, and you would have to be
> careful not to copy everywhere.
>
> My impression was that Pull-like interfaces -- lazy parsing of XML as it is
> being iterated -- were more popular.
>

Can't say I'm an expert on lazy parsing of XML, but there's certainly
pros & cons between SAX & DOM based parsers, and I would assume the
same holds true for lazy parsers ( which I presume would have a DOM
like interface ). For example, access which is non linear would
perhaps have inferior runtime characteristics compared to eager
variants as the media access often becomes the bottleneck. In any case
I think there's a lot of interesting implementation details which no
C++ XML library seems to have got quite right yet, using spirit or not
naturally would come down to whomever would be interesting to have a
go at it. Another detail which could be interesting is parametrizing
the tag/attribute name, as there's usually quite a few duplicates
boost::flyweight<> could be a big win in a lot of use cases for a
fairly small effort. Overall I'm very confident that a top notch XML
library would get a ton of use and be a popular addition.

I also certainly agree with Joel, I would even go as far as saying
there's perhaps a few libraries which should be kicked out of the
distribution. Overall I feel there's a few libraries which have no
place in a production environment, having gone to far down their own
rabbit hole so to speak. Some are to close in what they're trying to
solve and should be merged.