Есть с++ чисто нейтивный проект.
Нужно сохранять и загружать конфигурацию.
Что посоветуете?

Увидел — http://www.codeproject.com/Articles/18732/XML-Include-a-Flexible-Parser-in-Your-C-Applicatio

Include a Flexible Parser in Your C++ Applications

Мне нравится что это простое не замороченное решение. Бесплатное, и переносимое.
Что за велосипед я изобретаю и на какие грабли наеду?

Здравствуйте, Аноним, Вы писали:

А>Есть с++ чисто нейтивный проект.
А>Нужно сохранять и загружать конфигурацию.
А>Что посоветуете?

Так вам XML или конфу?
Если конфигурация, я бы взял что-то полегче. JSON например. Потому как читать и править руками XML занятие не самое приятное.
Если же нужен именно XML, можно для плюсов взять TinyXML?. Маленький (хедер плюс один файл исходника), простой.
А вот брать Xerces-c не советую. У её архитекторов кажется ООП головного мозга. Одно только количество классов и 4 (!!!) независимых иерархии исключений.

Здравствуйте, Аноним, Вы писали:

А>Есть с++ чисто нейтивный проект.
А>Нужно сохранять и загружать конфигурацию.
А>Что посоветуете?

Что-нибудь простенькое.
PugiXml, RapidXml — самое оно.

А>Увидел — http://www.codeproject.com/Articles/18732/XML-Include-a-Flexible-Parser-in-Your-C-Applicatio

А>

А>Include a Flexible Parser in Your C++ Applications

А>Мне нравится что это простое не замороченное решение. Бесплатное, и переносимое.
А>Что за велосипед я изобретаю и на какие грабли наеду?

Почитал. Запросы по сети, ADO, шифрование — нифига не просто и не замороченно. Зачем все эти свистоперделки для конфигов?
Библиотечка для работы с XML должна парсить и создавать XML. Точка. Если есть какие-то дополнительные перделки — значит, автор делает не библиотеку, а гибрид слона и удава. Оно вам надо?

На самом деле, полноформатная работа с XML (кодировки, валидация, трансформация) — штука сложная, не зря всякие монстры типа Xerxes живут.

Здравствуйте, Аноним, Вы писали:

А>Есть с++ чисто нейтивный проект.
А>Нужно сохранять и загружать конфигурацию.
А>Что посоветуете?

boost::program_options будет достаточно.

codeproject отличается больными идеями и низким качеством реализации. глянь вот на этот. на нем всё сведено в одну сущность — узел.

А>Есть с++ чисто нейтивный проект.
А>Нужно сохранять и загружать конфигурацию.
А>Что посоветуете?

boost::property_tree

Здравствуйте, Мишень-сан, Вы писали:

МС>Так вам XML или конфу?
МС>Если конфигурация, я бы взял что-то полегче. JSON например. Потому как читать и править руками XML занятие не самое приятное.

Можно YAML еще использовать. Он вроде как подружелюбнее JSONа в плане редактирования. Или вообще — INI-style конфиги, для их парсинга/сохранения даже библиотеки не надо, все десять строчек парсера пишутся на коленке за пять минут.

МС>Если же нужен именно XML, можно для плюсов взять TinyXML?. Маленький (хедер плюс один файл исходника), простой.

По сравнению с RapidXml он жирнее, медленнее, и линкуется отдельной библиотекой.
С другой стороны, при создании XML через RapidXml нужно написать чуть больше кода (надо вызывать аллокаторы для копирования нестатических данных вовнутрь объекта, если я правильно помню).

МС>А вот брать Xerces-c не советую. У её архитекторов кажется ООП головного мозга. Одно только количество классов и 4 (!!!) независимых иерархии исключений.

Согласен.
Xerces — это для серьезных, очень серьезных задач.

Здравствуйте, chemey, Вы писали:

C>Согласен.
C>Xerces — это для серьезных, очень серьезных задач.

Моё скромное ИМХО — я бы его вообще ни для чего не брал. Слишком переусложнённая на ровном месте вещь.

Здравствуйте, Мишень-сан, Вы писали:

МС>Моё скромное ИМХО — я бы его вообще ни для чего не брал. Слишком переусложнённая на ровном месте вещь.

сейчас придет okman и расскажет тебе, как ты неправ

Здравствуйте, о_О, Вы писали:

о_О>Здравствуйте, Мишень-сан, Вы писали:

МС>>Моё скромное ИМХО — я бы его вообще ни для чего не брал. Слишком переусложнённая на ровном месте вещь.

о_О>сейчас придет okman и расскажет тебе, как ты неправ

Не, переубеждать никого не собираюсь, тем более, что человек написал "ИМХО", и высказанная
точка зрения совершенно понятна. А вообще, я сам не знаю, как в наше время принято решать такие
задачи, как чтение-запись конфигов.

С одной стороны, для таких простых вещей не нужен ни XML, ни его имплементации в лице монструозных
Xerces, libxml и остальных — подойдет самый обычный INI-файл или вообще какой-нибудь CSV.

А с другой — стоит хотя бы задуматься о том, во что это "чтение-запись" может превратиться через
годик-другой, когда потребуется (вдруг!) часто менять формат, сделать его переносимым между платформами,
заставить понимать разные кодировки, и под все это дело каждый раз подыскивать или переписывать
парсинг... Нет уж, спасибо. Если задача подразумевает какое-то масштабирование, лучше сразу
выбрать инструмент с расчетом на будущее, и закрыть себя от многих подобных проблем.

В моем случае таким инструментом оказался Xerces. Ну да, его API мрачноват, но я видел куда
более отвратные программные интерфейсы со структурами в полторы сотни полей и невнятными контрактными
соглашениями, приводившими при неверном использовании API не к явным и документированным ошибкам,
как должно быть во всех нормальных либах, а к глюкам в местах, зависящих от версии библиотеки и
положения левого ботинка соседа с восьмого этажа. Xerces по сравнению с этим — милый пушистый
котенок, к тому же ничто не мешает написать несколько простых оберток или фасадов и все, мы имеем
простой и наглядный клиентский код. Да, и под Windows он элементарно собирается, чего не скажешь о
том же libxml++, который, по-моему, сильно уж unix-ориентирован в этом плане, хотя его API и поприятнее.

Плата за все удовольствие в совокупности — это "довесок" к бинарникам, в размере порядка одного
мегабайта, что по современным "расценкам" почти ничто.

Но это все также мое ИМХО, ничуть не менее ИМХО-вое, чем у Мишень-сан.

Здравствуйте, Centaur, Вы писали:

А>>Есть с++ чисто нейтивный проект.
А>>Нужно сохранять и загружать конфигурацию.
А>>Что посоветуете?

C>boost::program_options будет достаточно.

Она уже научилась создавать, а не только парсить конфиги?

Здравствуйте, Аноним, Вы писали:

А>Есть с++ чисто нейтивный проект.
А>Нужно сохранять и загружать конфигурацию.
А>Что посоветуете?
Если XML, то pugi, rapidxml, minixml.
Но вообще, лучше смотреть в сторону conf-файлов (подобие INI для юниксов) и библиотек к ним.

> Есть с++ чисто нейтивный проект.
> Нужно сохранять и загружать конфигурацию.
> Что посоветуете?

boost::program_options

Здравствуйте, Аноним, Вы писали:

А>Есть с++ чисто нейтивный проект.
А>Нужно сохранять и загружать конфигурацию.
А>Что посоветуете?

А>Увидел — http://www.codeproject.com/Articles/18732/XML-Include-a-Flexible-Parser-in-Your-C-Applicatio


А>

А>Include a Flexible Parser in Your C++ Applications

А>Мне нравится что это простое не замороченное решение. Бесплатное, и переносимое.
А>Что за велосипед я изобретаю и на какие грабли наеду?

http://jsoncpp.sourceforge.net/

Здравствуйте, Аноним, Вы писали:

А>Есть с++ чисто нейтивный проект.
А>Нужно сохранять и загружать конфигурацию.
А>Что посоветуете?

boost.property_tree...

Здравствуйте, SX, Вы писали:

SX>Здравствуйте, Аноним, Вы писали:

А>>Есть с++ чисто нейтивный проект.
А>>Нужно сохранять и загружать конфигурацию.
А>>Что посоветуете?

pugixml -- small and fast

Здравствуйте, MasterZiv, Вы писали:

>> Есть с++ чисто нейтивный проект.
>> Нужно сохранять и загружать конфигурацию.
>> Что посоветуете?

MZ>boost::program_options

Эта либа не писатель, а читатель. В отличие от.

Здравствуйте, okman, Вы писали:

O>Здравствуйте, о_О, Вы писали:

о_О>>Здравствуйте, Мишень-сан, Вы писали:

O>С одной стороны, для таких простых вещей не нужен ни XML, ни его имплементации в лице монструозных
O>Xerces, libxml и остальных — подойдет самый обычный INI-файл или вообще какой-нибудь CSV.

Я просто в последнее время насмотрелся на XML из одних нодов с именами по 10-15 знаков и степенью вложенности 8-10 уровней. Причём с конструкциями вроде:

<MySuperPuperObjects>
  <MySuperPuperObject>
    <Name>objname</Name>
  </MySuperPuperObject>
</MySuperPuperObjects>

Это не то что редактировать — читать тяжело.

O>А с другой — стоит хотя бы задуматься о том, во что это "чтение-запись" может превратиться через
O>годик-другой, когда потребуется (вдруг!) часто менять формат, сделать его переносимым между платформами,
O>заставить понимать разные кодировки, и под все это дело каждый раз подыскивать или переписывать
O>парсинг... Нет уж, спасибо. Если задача подразумевает какое-то масштабирование, лучше сразу
O>выбрать инструмент с расчетом на будущее, и закрыть себя от многих подобных проблем.

Опять же, есть шанс словить синдром AbstractFactoryProxyMixinSingleton. Но ИМХО если обычная конфа превращается в РБД, одной переделкой парсера не отделаешься. А парсер... Парсер должен работать над потоком юникод-токенов. Вычитка напрямую из источника и приведение к юникоду не его забота.

O>В моем случае таким инструментом оказался Xerces. Ну да, его API мрачноват, но я видел куда
O>более отвратные программные интерфейсы...

Это да, за такое надо автора сковородкой по башке Помню свои разборки с вещичкой под названием dbVista в начале карьеры. Как сетевая база (в смысле организации) вполне ничего, даже АПИ на КА я считаю вполне адекватным, но на ряд штатных ошибок эта падла ложила весь процесс ассёртом, не давая даже среагировать.

O>Плата за все удовольствие в совокупности — это "довесок" к бинарникам, в размере порядка одного
O>мегабайта, что по современным "расценкам" почти ничто.

Дык про размер бинарей вроде никто и не говорит. Метр или два, особенно если система и так большая, уже рояли не играет.