yaml-cpp & boost:any: merge functionality
Closed this issue · 6 comments
Оба названных решения реализуют практически одинаковый функционал: хранение любых типов данных. В какой-то момент имеет смысл избавить код от перегруженных мест, вызванных стековкой yaml-cpp и boost::any.
При это если мы остаемся с бустом, то придется фактически реализовывать свой парсер и эмиттер языка yaml на основе boost::any, чтобы закрыть функциональность ямла, связанную с файлами.
Вполне возможно, что yaml-cpp окажется тем решением, которое в случае хранения личных данных объектов подойдет больше "голого" boost::any.
Я бы предпочел boost по четырем причинам:
- он стабильнее (new-api на то и new-api, что может часто меняться, пока не попадет в основную ветку, делать проект зависимым от изменений в сторонней библиотеки очень не хочется, да и менеджеры пакетов о новой версии еще не знают);
- он функциональнее;
- он надежнее - это продукт разрабатываемый как библиотека общего назначения, проверенный в огромном количестве проектов, а потому контроль за качеством кода в нем на абсолютно ином уровне.
- я все еще не хочу оставлять yaml в качестве основного способа хранения данных в файлах.
И да, уже сейчас мне очень хочется добавить опцию WITH_YAML, пусть даже включенную по умолчанию. У меня создается впечатление, что сейчас, когда мы дошли до тестирования, мы будем наблюдать интерференционную картину из багов, вылезающих в разных местах программы, а потому лучше сразу сделать возможность отключать части которые можно тестировать независимо.
P.S. Да отдельным аргументом за введение опции WITH_YAML выдвигаю то, что не хочу ставить в систему что-либо в обход portage, в которой yaml-cpp сейчас есть только стабильной версии (0.3.0), также не считаю целесообразным писать ebuild, т.к. мэинтейнер в любом случае сделает это лучше меня.
мне не нравится идея использовать yaml для чего-либо кроме загрузки и сохранения данных
О чем я и говорил. Сейчас мне сильно мешало то, что часть с yaml не собирается из-за не совпадения версий библиотеки. Добавил опцию WITH_YAML, включил по умолчанию. Код, который требует наличия YAML прошу оборачивать:
#ifdef WITH_YAML
/* some code with yaml */
#endif /* WITH_YAML */
Насчет макроса WITH_YAML. Конечно же он нужен, только я его не создавал, т. к. очень уж C-Style выглядит wrapp-ить код таким образом. Но скоро, я думаю, ямл перейдет в отдельный модуль, тогда будет проще.
Насчет yaml versus boost проблемы.
Полностью согласен, что переходить на пока что не вышедший бранч библиотеки нельзя, а использовать старый api грустно из-за превосходства нового. => пока что ничего не трогаем.
Но какая нам нужна супер-функциональность от мознейшей boost::any? Нам, по-сути, нужен механизм работы с гибкими VCard-ами, как я их называю, т. е. анкетой объекта. Больше ничего плавающего у нас нет, а сами эти анкеты логически являются лишь содержимым контейнеров, т. е. на алгоритмы вообще это не затрагивают.
Поэтому супер функциональность буста некорректна.
Надежность тут тоже спорная вещь, CMake, например, как и git, не имеют статуса самых надежных решений индустрии, но мы из за удобство выбрали, о чем я не жалею. Приемлемая надежность, которой вообще хватает для наших целей, есть и у yaml-cpp.
Насчет основного способа хранения данных в файле. Сам формат является вполне удобным. Сравнивая его с JSon и xml могу сказать, что он более гибкий и общий, в то же время минималистичный. Так что неясно, к чему ты, alex-ac, клонишь. При этом, как я уже говорил, yaml-cpp скоро можно будет переместить в отдельный модуль, что по-идее должно сохранить тебе массу нервных клеток.
P.S. Я уважаю твою ОС, но в принципе то что тебе неудобно ставить какой-либо software, который нам нужен для разработки, тоже не является аргумнтом. Хотя, вероятнее всего, через какое-то время yaml-cpp в master дорастет до версии 0.5 и ты сможешь ни в чем себе не отказывать.
эти места только в импорте и экспорте данных, не вижу больших проблем. Давайте не разводить демагогию на эту тему?