![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Toml на Си++
Понадобилось мне по работе в одном проекте задействовать конфигурационные файлы. До этого параметры приложения задавались обычными флагами в командной строке. Но когда параметров становится слишком много - проще записать их в скрипт конфигурации.
Конфигурационные скрипты бывают в разных видах: Json, Yaml, Ini, XML, Toml. Я выбрал Toml как самый простой для непосвящённых. Думал, быстренько схвачу первую попавшуюся библиотечку для Си++, и будет готово. Оказалось несколько труднее.
Я перебрал три реализации Toml для Си++. Со всеми возникли проблемы разной степени сложности.
1. TOML++, она же tomlplusplus. Самая продвинутая и распространённая библиотека. Присутствует в пакетах на Линуксе, Маке и везде. Якобы легко подключается через CMake - не верьте. Пробовал просто скопировать её исходник в свой проект, благо есть header-only версия. Но у меня ж все ворнинги включены (-Wall -Werror), в том числе -Wshadow. Плюс к тому обязательный cppcheck. А исходников в том файле toml.hpp аж 18000 строк. 475 килобайт кода на минуточку. Компилятор вкупе с cppcheck там столько всякого находят - мама не горюй. Ф топку.
2. Toml11. Тоже якобы неплох. Тоже громоздкий файл toml.hpp из примерно 18000 строк, уже 552 килобайта. И тоже лезет куча ворнингов от компилятора и ошибок от cppcheck. Нет сил с ними бороться.
3. Cpptoml. Файл cpptoml.h намного меньше, всего 3700 строк, порядка 90 килобайт. И фигни из него лезет немного: я за пятнадцать минут подчистил все хвосты. Вроде делает всё что требуется, вполне годный вариант.
Вывод: опенсорс это здорово, и иногда сильно помогает в работе. Но за качеством кода придётся следить самому.
Конфигурационные скрипты бывают в разных видах: Json, Yaml, Ini, XML, Toml. Я выбрал Toml как самый простой для непосвящённых. Думал, быстренько схвачу первую попавшуюся библиотечку для Си++, и будет готово. Оказалось несколько труднее.
Я перебрал три реализации Toml для Си++. Со всеми возникли проблемы разной степени сложности.
1. TOML++, она же tomlplusplus. Самая продвинутая и распространённая библиотека. Присутствует в пакетах на Линуксе, Маке и везде. Якобы легко подключается через CMake - не верьте. Пробовал просто скопировать её исходник в свой проект, благо есть header-only версия. Но у меня ж все ворнинги включены (-Wall -Werror), в том числе -Wshadow. Плюс к тому обязательный cppcheck. А исходников в том файле toml.hpp аж 18000 строк. 475 килобайт кода на минуточку. Компилятор вкупе с cppcheck там столько всякого находят - мама не горюй. Ф топку.
2. Toml11. Тоже якобы неплох. Тоже громоздкий файл toml.hpp из примерно 18000 строк, уже 552 килобайта. И тоже лезет куча ворнингов от компилятора и ошибок от cppcheck. Нет сил с ними бороться.
3. Cpptoml. Файл cpptoml.h намного меньше, всего 3700 строк, порядка 90 килобайт. И фигни из него лезет немного: я за пятнадцать минут подчистил все хвосты. Вроде делает всё что требуется, вполне годный вариант.
Вывод: опенсорс это здорово, и иногда сильно помогает в работе. Но за качеством кода придётся следить самому.
no subject
no subject
no subject
no subject
А если нужно что то многоуровневое, то да ini слишком простой.
no subject
no subject
no subject
А стандартные библиотеки, в отличие от произвольных исходников, и не требуют доработки напильником, и оттестированы.
no subject
Вобще эти два ключа должны быть по умолчанию и всегда включены. И что-бы отключить было нельзя. Я думаю процентов 30 всех дырок в софте это закрыло бы. Тот-же раст, прости господи, такой типа надёжный код генерит не потому что он какой-то особенный, а потому что у него варнингов почти нет - чуть что, сразу по рукам бъёт.
no subject
Потому что это еще не ошибки.
'More what you'd call "guidelines" than actual rules'.
И дополняются эти гайдлайны в каждой новой версии компилятора.
У себя в
спальнеофисе consenting adults могут делать что угодно, но в выкладываемом публично -Werror быть не должно. Потому что через год будет новый компилятор с пачкой новых ворнингов и оно уже не соберется без ручных правок или без перехода на новую версию, в которой, как обычно, длинный список breaking changes, или которой просто нет, потому что автор забил или вообще принял ислам.no subject
Предупреждение - это потенциальная ошибка. Если это не так - это место должно быть обвешано прагмами, которые дадут проскочить его (причём не отключая сам по себе варнинг).
Использовать библиотеку, которая в процессе сборки вываливает кучу предупреждений - такая себе идея.
no subject
Разумеется, предупреждения, как правило, осмысленны и при разработке надо включать все возможное и исправлять сразу же, желательно принудительно.
Я о том, что -Werror не должен протекать в финальный продукт (если продукт - это код и не header only), потому что мы не знаем, чем и через сколько лет его будут собирать.
-Wall, например, включает и всякие -Wc++XX-compat, т.е. даже заведомо полностью корректный код, даже собираемый под явно указанный стандарт, лет через 5 может начать генерировать предупреждения о том, что в следующем стандарте что-то там поменяется, имейте в виду, что в целом интересно и пригодится лет через 10, когда мы будем на этот стандарт переходить, но еще не повод ломать сборку прямо сейчас.
При этом есть множество полезных предупреждений, не включенных ни в -Wall, ни в -Wextra.
Потому что если их туда включить, то сломается полмира.
Потому что куча людей навставляла -Werror, не думая о последствиях.
И единственный способ узнать, что они вообще есть - регулярно перечитывать вот эту простыню.
no subject
no subject