Як і у стандартних бібліотечних контейнерах, яку бібліотеку ви повинні використовувати, залежить від ваших потреб. Ось зручна блок-схема:
Тож перше питання таке: що вам потрібно?
Мені потрібна повна відповідність XML
Гаразд, тому вам потрібно обробити XML. Не іграшка XML, справжня XML. Потрібно вміти читати та записувати всю специфікацію XML, а не лише розрядні біти, що легко розбираються. Вам потрібні простори імен, DocTypes, підміна сутності, твори. Специфікація W3C XML в цілому.
Наступне питання: чи повинен ваш API відповідати DOM чи SAX?
Мені потрібна точна DOM та / або відповідність SAX
Гаразд, значить, вам дійсно потрібен API, щоб бути DOM та / або SAX. Це не може бути просто аналізатор натискання в стилі SAX або збережений парсер у стилі DOM. Він повинен бути фактичним DOM або фактичним SAX, наскільки це дозволяє C ++.
Ви вибрали:
Ксерси
Це ваш вибір. Це майже єдиний C ++ XML-аналізатор / записувач, який має повну (або настільки близьку, як це дозволяє C ++) DOM та SAX. Він також має підтримку XInclude, підтримку XML-схеми та безліч інших функцій.
Він не має реальних залежностей. Він використовує ліцензію Apache.
Мене не хвилює відповідність DOM та / або SAX
Ви вибрали:
LibXML2
LibXML2 пропонує інтерфейс у стилі С (якщо це насправді турбує вас, перейдіть на Xerces), хоча інтерфейс є хоча б дещо об'єктним і легко перетворюється. Він надає безліч функцій, як підтримка XInclude (із зворотними дзвінками, щоб ви могли повідомити, звідки він отримує файл), розпізнавальник XPath 1.0, підтримка RelaxNG та Schematron (хоча повідомлення про помилки залишають бажати кращого) та т.д.
Він має залежність від iconv, але його можна налаштувати і без цієї залежності. Хоча це означає, що у вас буде більш обмежений набір можливих текстових кодувань, які він може розібрати.
Він використовує ліцензію MIT.
Мені не потрібна повна відповідність XML
Гаразд, тому повне відповідність XML для вас не має значення. Ваші документи XML повністю або під вашим контролем, або гарантовано використовувати "основний підмножина" XML: немає просторів імен, об'єктів тощо.
То що вам важливо? Наступне питання: що для вас найважливіше в роботі XML?
Максимальна продуктивність розбору XML
Вашій програмі потрібно взяти XML і перетворити її в структуру даних C ++ так швидко, як це можливо, перетворення.
Ви вибрали:
RapidXML
Цей XML-аналізатор - це саме те, що написано на бляшанці: швидкий XML. Це навіть не стосується витягування файлу в пам'ять; як це відбувається, залежить від вас. Те, з чим він працює, - це аналіз їх на низку структур C ++, до яких можна отримати доступ. І це робиться приблизно так швидко, як потрібно для сканування файлу в байті.
Звичайно, немає такого поняття, як безкоштовний обід. Як і більшість парсерів XML, яким не важливо специфікацію XML, Rapid XML не торкається просторів імен, DocTypes, сутностей (за винятком сутності символів та 6 основних XML) тощо. Отже, в основному, вузли, елементи, атрибути тощо.
Крім того, це аналізатор стилю DOM. Тому потрібно прочитати весь текст. Однак те, що він не робить, - це скопіювати будь-який із цього тексту (як правило). Швидкість, з якою RapidXML отримує більшу частину своєї швидкості, - це перехід до рядків на місці . Це вимагає більшого управління пам’яттю з вашого боку (ви повинні підтримувати цей рядок живим, поки RapidXML дивиться на нього).
DOM RapidXML - це голі кістки. Ви можете отримати рядкові значення для речей. Ви можете шукати атрибути за іменем. Ось про це. Немає функцій зручності, щоб перетворити атрибути в інші значення (числа, дати тощо). Ви просто отримуєте струни.
Ще одним недоліком у RapidXML є те, що він болісно пише XML. Це вимагає, щоб ви зробили багато явного розподілу пам'яті імен рядків, щоб створити свою DOM. Він надає певний буфер рядків, але це все ще потребує великої явної роботи у вашому кінці. Це, звичайно, функціонально, але це біль.
Він використовує ліцензію MIT. Це бібліотека, лише для заголовків, без залежностей.
Я дбаю про продуктивність, але не дуже багато
Так, для вас важлива продуктивність. Але, можливо, вам потрібно щось трохи менше босих кісток. Можливо, щось, що може працювати з більшою кількістю Unicode, або не вимагає стільки управління пам'яттю, керованої користувачем Продуктивність все ще важлива, але ви хочете чогось менш прямого.
Ви вибрали:
PugiXML
Історично це служило натхненням для RapidXML. Але два проекти розійшлися, і Pugi пропонує більше можливостей, тоді як RapidXML повністю орієнтований на швидкість.
PugiXML пропонує підтримку конверсії Unicode, тому якщо у вас є кілька документів UTF-16 і хочете прочитати їх як UTF-8, Pugi надасть. Він навіть має реалізацію XPath 1.0, якщо вам потрібна така річ.
Але Пугі все ще досить швидкий. Як і у RapidXML, він не має залежностей і поширюється під ліцензією MIT.
Читання величезних документів
Вам потрібно прочитати документи, які вимірюються в гігабайтах за розміром. Можливо, ви отримуєте їх від stdin, годуючись якимись іншими процесами. Або ви читаєте їх з масивних файлів. Або що завгодно. Справа в тому, що вам потрібно - не робити потрібно читати весь файл у пам'яті відразу, щоб обробити його.
Ви вибрали:
LibXML2
API SAX-стилю Xerces працює в цій якості, але тут є LibXML2, оскільки з цим трохи простіше працювати. API стилю SAX - це push-API: він починає розбирати потік і просто запускає події, які вам доведеться спіймати. Ви змушені керувати контекстом, станом тощо. Код, який читає API в стилі SAX, набагато більше, ніж можна сподіватися.
Об'єктом LibXML2 xmlReader
є API API. Ви просите перейти до наступного вузла або елемента XML; вам не кажуть. Це дозволяє зберігати контекст так, як вам здається, обробляти різні об'єкти таким чином, що в коді можна читати набагато більше, ніж купу зворотних викликів.
Альтернативи
Експат
Expat - це відомий аналізатор C ++, який використовує API "pull-parser". Це написав Джеймс Кларк.
Поточний статус активний. Найновіша версія - 2.2.9, яка вийшла в світ (2019-09-25).
LlamaXML
Це реалізація API стилю StAX. Це pull-аналізатор, схожий на xmlReader
аналізатор LibXML2 .
Але він не оновлювався з 2005 року. Отже, знову, Caveat Emptor.
Підтримка XPath
XPath - це система запиту елементів у дереві XML. Це зручний спосіб ефективного іменування елемента або колекції елемента за загальними властивостями, використовуючи стандартизований синтаксис. Багато бібліотек XML пропонують підтримку XPath.
Тут є три варіанти:
- LibXML2 : Він забезпечує повну підтримку XPath 1.0. Знову ж таки, це API API, тож якщо це вас турбує, є альтернативи.
- PugiXML : Також він постачається з підтримкою XPath 1.0. Як вище, це більше API C ++, ніж LibXML2, тому вам може бути зручніше з ним.
- TinyXML : Він не постачається з підтримкою XPath, але є бібліотека TinyXPath, яка забезпечує його. TinyXML проходить перехід до версії 2.0, що суттєво змінює API, тому TinyXPath може не працювати з новим API. Як і сам TinyXML, TinyXPath поширюється під ліцензією zLib.
Просто займіть роботу
Отже, вам не байдуже правильність XML. Продуктивність не є проблемою для вас. Трансляція не має значення. Все, що вам потрібно, - це те, що отримує XML в пам’яті і дозволяє вам знову вставити його на диск. Що вас цікавить - це API.
Ви хочете, щоб аналізатор XML був невеликий, простий в установці, тривіальний у використанні та досить малий, щоб не мати значення для вашого можливого розміру виконуваного файлу.
Ви вибрали:
TinyXML
Я помістив TinyXML в цей слот, тому що він приблизно такий, як braindead простий у використанні, як отримують XML-аналізатори. Так, це повільно, але це просто і очевидно. Він має багато зручних функцій для перетворення атрибутів тощо.
Написання XML не є проблемою в TinyXML. Ви просто new
підготуйте деякі об'єкти, з'єднайте їх, відправте документ на std::ostream
і всі задоволені.
Є також екосистема, побудована навколо TinyXML, з більш зручним для ітераторів API і навіть реалізацією XPath 1.0, що розміщена поверх нього.
TinyXML використовує ліцензію zLib, яка є більшою чи меншою мірою Ліцензією MIT з іншим іменем.