vak: (Default)
[personal profile] vak
Понадобилось мне по работе в одном проекте задействовать конфигурационные файлы. До этого параметры приложения задавались обычными флагами в командной строке. Но когда параметров становится слишком много - проще записать их в скрипт конфигурации.

Конфигурационные скрипты бывают в разных видах: 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 килобайт. И фигни из него лезет немного: я за пятнадцать минут подчистил все хвосты. Вроде делает всё что требуется, вполне годный вариант.

Вывод: опенсорс это здорово, и иногда сильно помогает в работе. Но за качеством кода придётся следить самому.

Date: 2024-10-30 12:06 (UTC)
From: [personal profile] nz

какого фига софт собирается без -Wall -Werror

Потому что это еще не ошибки.
'More what you'd call "guidelines" than actual rules'.
И дополняются эти гайдлайны в каждой новой версии компилятора.

И что-бы отключить было нельзя

У себя в спальне офисе consenting adults могут делать что угодно, но в выкладываемом публично -Werror быть не должно. Потому что через год будет новый компилятор с пачкой новых ворнингов и оно уже не соберется без ручных правок или без перехода на новую версию, в которой, как обычно, длинный список breaking changes, или которой просто нет, потому что автор забил или вообще принял ислам.

Date: 2024-10-30 12:47 (UTC)
ufm: (Default)
From: [personal profile] ufm
C/C++ достаточно сложные языки с кучей легаси и UB. Лет десять назад еще по ЖеЖешечке ходила развлекуха - как разные компиляторы компилируют выряжение i = 5; a = i++ + ++i;
Предупреждение - это потенциальная ошибка. Если это не так - это место должно быть обвешано прагмами, которые дадут проскочить его (причём не отключая сам по себе варнинг).

Использовать библиотеку, которая в процессе сборки вываливает кучу предупреждений - такая себе идея.

Date: 2024-10-30 13:42 (UTC)
From: [personal profile] nz

Разумеется, предупреждения, как правило, осмысленны и при разработке надо включать все возможное и исправлять сразу же, желательно принудительно.
Я о том, что -Werror не должен протекать в финальный продукт (если продукт - это код и не header only), потому что мы не знаем, чем и через сколько лет его будут собирать.

-Wall, например, включает и всякие -Wc++XX-compat, т.е. даже заведомо полностью корректный код, даже собираемый под явно указанный стандарт, лет через 5 может начать генерировать предупреждения о том, что в следующем стандарте что-то там поменяется, имейте в виду, что в целом интересно и пригодится лет через 10, когда мы будем на этот стандарт переходить, но еще не повод ломать сборку прямо сейчас.

При этом есть множество полезных предупреждений, не включенных ни в -Wall, ни в -Wextra.
Потому что если их туда включить, то сломается полмира.
Потому что куча людей навставляла -Werror, не думая о последствиях.
И единственный способ узнать, что они вообще есть - регулярно перечитывать вот эту простыню.

Date: 2024-10-30 20:22 (UTC)
ufm: (Default)
From: [personal profile] ufm
Вот именно потому что мы не знаем кто, когда и чем будет собирать нашу библиотеку - лучше был-бы не отключаемый Werror, которй можно обойти только прагмами на конкретном месте.Ибо что там наколдовали в новом компиляторе, какие косяки вылезут, что там в результате заглючит- мы не знаем. А так есть надежда что человек, который нашу библиотеку через 10 лет решил использовать хотя-бы посмотрит что там могло отвалиться, а не "хуяк-хуяк и в продакшен".