| ▲ | remus 5 days ago | |
This process usually goes: 1. "This XML library is way bigger than what I need, I'll write something more minimal for my use case" 2. write a library for whatever minimal subset you need 3. crash report comes in, realise you missed off some feature x. Add support for some feature x. 4. Bob likes your library. So small, so elegant. He'd love to use it, if only you supported feature y, so you add support for feature y. ... End result is x+1 big, complex XML libraries. Obviously Im being a bit obtuse here because you might be able to guarantee some subset of it in whatever your specific circumstances are, but I think it's hard to do over a long period of time. If people think you're speaking XML then at some point they'll say "why don't we use this nice XML feature to add this new functionality". | ||
| ▲ | bayindirh 5 days ago | parent | next [-] | |
If you want to read some XML quickly, there's always RapidXML and PugiXML, but if you need a big gun, there's libXML. The former are blazingly fast. In real world they can parse instantly. So alternatives do exist for different use cases. | ||
| ▲ | hulitu 4 days ago | parent | prev [-] | |
> Obviously Im being a bit obtuse here No. This is the first good expkanation for the library hell in linux those days. | ||