День добрый!
Хотелось бы узнать у обитателей данного форума: какими либами вы пользуетесь для разбора конфигов к своим приложениям
название, +- на ваш взгляд, может кто пользовался несколькими - сравните

Заранее благодарен!

chaos, Я использую свой вариант. Сам написал с нуля. Так как, когда мне такое понадобилось, начал искать, и нечего удовлетворяющего моим запросам не нашел.

Лично я так, как в основном пишу на билдере использую TIniFile.

В случаях, когда конфиг слишком сложный и неудобный для представления в текстовом виде - пишу сам, в виде набора структур.

GetPrivateProfile*()

как и Anikmar, пользуясь Борманом, использую TIniFiles.
Однако не гнушаюсь и БД - слишком много было данных - поэтому использовать настроечную таблицу был очень кашерный выход.

А какой? Я что-то подходящее не нашел, чтобы было небольшое и можно было вместе с программой таскать и запускать на другом компе без каких-либо дополнительных установок.

MDB + ADO 


Под винду:
GetPrivateProfileInt
GetPrivateProfileSection
GetPrivateProfileSectionNames
GetPrivateProfileString
GetPrivateProfileStruct
GetProfileInt
GetProfileSection
GetProfileString
WritePrivateProfileSection
WritePrivateProfileString
WritePrivateProfileStruct
WriteProfileSection
WriteProfileString
....

Это сообщение отредактировал(а) Alca - 25.3.2009, 12:07

Крайне не удобные функции. Хоть бы обертку в виде класса написать... )))

чаще всего - реестр windows, однажды использовал lua(удобно, когда конфиги должны редактироваться юзером), БД то-же неплохой вариант

andrew_121, +1 тож сам писал 

QSettings   

Это сообщение отредактировал(а) Helmet - 25.3.2009, 12:19

скажем так - в данном случае настроечная таблица и была к базе данных, поэтому отдельно бд конечно не использовалась. Сама БД была на MySQL. А так хоть тот же Access. Работать будет нормально и без офиса. Это конечно под винду. Так же думаю покатит и LiteSQL. Да и что СУБД мелких мало что ли, которые не требуют инсталяции.

XML

Да. Только если проект использует ее не только ради этого. А иначе, смысл = 0 )

конфиги храню в xml, разбираю своим классом на базе msxml

Крайне не удобные, пока не напишешь врапер. 

chaos, использую то что есть в стандарте, то чего нету - пишу сам (если речь конечно идет о чистом С++). А так у каждой библиотеки свои классы (о них тут уже написано немало).

написал два сообщения

Это сообщение отредактировал(а) Andrey44 - 25.3.2009, 12:59

Чем XML лучше INI? 

Не совсем понял высказывание по поводу смысла.  

Это сообщение отредактировал(а) Andrey44 - 25.3.2009, 12:57

иксмл может иметь более вложенную структуру.

Лично у меня душа к XML не лежит. Не вижу никаких преимуществ для использования в качестве хранилища конфигурации.
Реестр по большей части не подходит - так как проект запускается с флешки и должен все у себя хранить.

Anikmar, в дот.нет есть XML серилизация, очень удобно для хранения конфигурации. Можно сразу сохранить обьект класса в файл, со всеми его данными.

Это сообщение отредактировал(а) azesmcar - 25.3.2009, 13:11

Alca, 
Чем XML лучше INI?  
структурированностью, возможностью жесткой валидации по схеме

в случае использования xml, встает вопрос о сохранности данных, например в ситуации, когда во время сохранения данных в конфиг. файл отключают электричество, нажимают на reset, кончается место на диске, или происходит ошибка в программе.
В этом случае, ваш конфигурационный файл может остаться в невалидном состоянии, что может привести к невозможности запуска программы и необходимости ее переустановки.
Именно поэтому, лучше использовать БД(с поддержкой транзакций(например  sqlite)) или реестр(который именно для этого и предназначен), или изобретать велосипед, пытаясь реализовать сохранение в файл атомарно.  

И еще базовый синтаксис языка XPath похож на адресацию в файловой системе.
Очень легко читать и писать данные.

Добавлено через 4 минуты и 6 секунд
БД надо с собой таскать в смысле длл а xml есть всегда. По крайней мере в Windows

Гм... Спасибо за комментирование...

Речь идет о том, что если для разбора вы юзаете libxml2, или что-то на ее основе, и в других целях она не используется в вашем проекте, то зачем тащить за проектом такого динозавра.

Anikmar, в дот.нет есть XML серилизация, очень удобно для хранения конфигурации. Можно сразу сохранить обьект класса в файл, со всеми его данными.

А Framework он не потребует в нагрузку?

потребует конечно 

я как пример преимущества для использования в качестве хранилища конфигурации. К тому же если нужно хранить иерархические данные - XML в самый раз.

А если не пользуюсь ничем подобным.
Есть просто интерфейсы IXMLDOM.............. и т.д.

Lazin, 
.. отключают электричество..
я вот кстати не в курсе, а что при этом будет в случае записи в реестр? Откат изменений?
вроде бы, *Transacted функции только в Vista и Server 2008 появились...

АДО есть в винде   

На вкус и на цвет... Подходы могут быть весьма различные. Но на этот случай у меня свой класс написан. Почему-то захотелось свое. Может, конечно, и велосипед, но не люблю xml и все тут.   

Alca, 
АДО есть в винде
только в случае mdb (jet engine) получаем гемор в 64-битной среде. а в наше время закрывать глаза на поддержку 64-битной платформы - это как прятать голову в песок :gigi:

это смотря для каких.

Добавлено через 2 минуты и 5 секунд
Rififi, 

более того еще полно машин и с 2000 маздаем. там сплошь и рядом 3 версия Jet'a - это если без SP

Anikmar, 
чисто интереса для.
как бы ты хранил в ini и доставал/записывал данные из вот такого конфига:

А что хранить то вообще надо (слаб я в разметке xml - каюсь)

Anikmar, 
А что хранить то вообще надо
всё, что выделено синим и обычным шрифтом, то есть аттрибуты (org.jboss.mq.server.jmx.Queue, ...) и тела (queue/tutorial/example, ...) нодов (server, mbean, ...) а также их взаимное расположение друг относительно друга в иерархии

Т.е что-то типа того должно получиться?
[Server]
code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=tutorial"
JNDIName=queue/tutorial/example
DestinationManager=jboss.mq:service=DestinationManager

Если серверов несколько можно и так:
[GENERAL]
ServerCount=4

[Server1]
... Необходимые настройки
[Server2]
... Необходимые настройки

Я не говорю, что INI это панацея. Я просто говорю, что мне не нравится xml и не было случая в моей практике, когда я бы спокойно не мог без него обойтись. Может такой случай и наступит. 
Мои конфиги как правило - прстой набор имен параметров и их значений.

Прошу прощения, кодю в основном для Linux. Там такого нет.
Это что-то вроде очередной  Мелкософтовской заморочки?  

andrew_121,
Это реализация парсера от ms, основанная на компонентной модели.

Добавлено через 8 минут и 28 секунд
Anikmar, 

Если серверов несколько
несколько может быть не только серверов, но и нодов mbean, attribute внутре нода server
тогда "плоская" модель ini-фала начинает превращаться в тихий ужас

иногда можно встретить такой workaround

server.mbean.code=...
server.mbean.name=...
...

ну, может кому-то такие телеги и нравятся... :gigi:

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

всё это самому проверять? а может просто валиться из-за неправильного парсинга? :fear:
не, нафик такое сщастие 

xml удобно для программы а не для пользователя, простые конфиги легко запоминаются, а здесь ещё надо xml знать (то есть напрямую конфиг не подредактируешь, а то что-нибудь сломается и обратно не восстановишь)

Конфиги предпочитаю хранить в виде XML, использую минималистичный парсер TinyXML. Объёмные данные  предпочитаю хранить в БД и для клиентских приложений в этих целях использую sqlite.

libconfig

поддерживаю вариант XML

мы используем связку XML+INI. В XML у нас сама структура конфига, и из него есть ссылки на ini - вроде макросов: "%INI:path/section/value"

почему так? потому что некоторые администраторы (да и не только они) в упор не понят все спецсимволы которые нужно экранировать в XML, да и в общем-то сложно редактировать XML.

ессно на всё это написана ООП надстройка, которая для программиста скрывает все "предести" )

XML via tinyXML

использую xml конфиг файлы. для формирования\чтения\редактирования применяю XML Archives из boost::serialization.

Ну, если нужна вложенность, что мешает использовать SQLite + значения типа 

уровеньвложения1/уровеньвложения2/уровеньвложения3/имяпараметра

Если приложение сложное, то дополнительные расходы на поддержку SQLite не так и заметны, а если небольшое приложение, то вложенность не нужна и можно спокойно прикрутить что-то своё с атомарной струкурой и возможностью отката, вмонтировав LZ компрессию для истории изменений типа открытого 7z. 

планирую использовать boost.PropertyTree

Простые храню в виде

#define key value

сложные - xml. Для обоих случаев написал простенькие парсеры.

Добавлено через 2 минуты и 50 секунд
Раньше еще пользовался чем-то похожим на .ini-файлы, с поддержкой древовидных конфигов и всяких плюшек вроде макросов и инклудов. Но там парсер получился сложный, однажды решил что-то изменить и сам запутался в собственном коде. Этот вариант конфигов вытеснил нынешний xml.