Как сделать поддержу конфигов в проге?

на чём пишешь, хоть скажи ;)

>на чём пишешь, хоть скажи ;)

Ах да забыл. С++ конечно ;)

Нет, ну почему же велосипед?

Если небольшой и несложный конфиг - то и написать маленький конфиг парсер очень легко. Собственно, выяснение данного вопроса в некоторых случаях занимает большее время нежели написание своего. И для плюсов это тоже верно. =)

можно свой написать, можно и http://www.azzit.de/dotconf/

>Нет, ну почему же велосипед?

>Если небольшой и несложный конфиг - то и написать маленький конфиг парсер очень легко. Собственно, выяснение данного вопроса в некоторых случаях занимает большее время нежели написание своего. И для плюсов это тоже верно. =)

Сейчас у меня реализовано две функции для чтения и записи конфига. И делается всё это вручную. Но добавлять новые переменные не удобно, и вобще не правильно как-то. Я решил написать класс для конфига что б всё делалось автоматически. Но подумал, ведь в огромном количестве прог есть конфиги и у всех одинаковый формат, может тогда существует стандартная библиотека, которая делает это хорошо. Это ведь UNIX-way. Только что нашел kconfig.h для KDE. Там формат конфига задается xml файлом, потом он компилируется и создается класс (h&cpp), который производит все манипуляции с конфигом. Хотелось бы такое же но без KDE :)

>можно свой написать, можно и http://www.azzit.de/dotconf/

Нда, с первого взгляда какой-то он кривой, буду разбираться. Спасибо за ссылку.

>Сейчас у меня реализовано две функции для чтения и записи конфига. И делается всё это вручную. Но добавлять новые переменные не удобно.

А никто и не спорит, что где-то хорошо и универсально. Вопрос в целесообразности.

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

Стандартной - нет. Я не знаю, по крайней мере для плюсов. Есть много самых разных.

>Это ведь UNIX-way. Только что нашел kconfig.h для KDE. Там формат конфига задается xml файлом, потом он компилируется и создается класс (h&cpp), который производит все манипуляции с конфигом. Хотелось бы такое же но без KDE :)

Ну смотри, предположим, у тебя небольшая программа. А теперь ты потащишь в зависимостях либу конфига, плюс все, что тащит она (xml-parser в данном случае). Вот и спрашивается, кто не помянет "добрым словцом" маленькую программу, для сборки которой придеться поставить кучу библиотек?

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

xml, GNOME registry

на lex/yacc легко пишется такая бодяга

А я сам писал через tinyxml

http://www.boost.org/doc/html/program_options.html

>Ну смотри, предположим, у тебя небольшая программа. А теперь ты потащишь в зависимостях либу конфига, плюс все, что тащит она (xml-parser в данном случае). Вот и спрашивается, кто не помянет "добрым словцом" маленькую программу, для сборки которой придеться поставить кучу библиотек?

В данном случае xml-parser нужен только разработчику. Запускаешь kconfig_compiler и получаешь хедеры, которые просто вставляешь в прогу.

>xml, GNOME registry

Не КДЕ так гном :)

>http://www.boost.org/doc/html/program_options.html

С виду вроде нормальная, как раз так как я и хотел. Установил libboost-dev, а там и намека на program_options нет. Это что ж каждому качать прийдется? Да еще и не GPL.

Мда, прийдется наверное самому писать :)

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

>Не, ну ви таки конечно будете смеяйца, но в большинстве случаев для поддержки конфигов достаточно шелла (его переменных окружения и wrapper-скриптика для запуска твоей программулины).

Это как? shell скрипт будет читать конфиг и передавать проге через командную строку?

Через коммандную строку - один из вариантов (избыточный, имеет смысл лишь тогда, когда и так есть разбор коммандной строки). А так - просто определяются переменные окружения в этом скрипте (или в скрипте, который он подгружает, a la $HOME/.bashrc для bash), и твоя программа эти переменные считывает.

А что в скрипте легче реализовать чтение конфига чем на си? Я просто в шелл скриптах плохо разбираюсь.

Ты не понял. Там вообще никакого чтения конфигов реализовывать не надо. 
Скрипт сам себе конфиг:

VAR1=100
VAR2="жёпа с метлой"
CONFDIR=$HOME/.myprogdir/

и т.п.

Главное преимущество такого подхода - конфиг может быть сколь угодно гибким (читать - скриптуемым).

Однако, если ты пользуешься интерпретируемым языком или языком, 
поддерживающим интерпретацию - то лучше использовать сам этот язык для 
конфигов. Если ты пользуешь дурацкий C++ - тогда вариант с шеллом - 
самый качественный.

если твой конфиг имеет простую одноуровненвую схему, что его структуру можно описать так

VAR1 VALUE1
VAR2 VALUE2
VAR3 VALUE3 ...

Таким образом, его его можно двольно просто отпарсить с помощью ifstream.

>Ты не понял. Там вообще никакого чтения конфигов реализовывать не надо. Скрипт сам себе конфиг

Понял, интересный подход :) Это где-то еще используется кроме .bashrc? Наверное так и сделаю.

>Если ты пользуешь дурацкий C++ - тогда вариант с шеллом - самый качественный.

Вот лишь бы обосрать.

>Таким обрзом, его его можно двольно просто отпарсить с помощью ifstream.

Отпарсить то не сложно, но сделать поддержку комментариев, обнаружение ошибок это уже...

Посмотри на startup-скрипты от всяких там JBoss, Tomcat, mozilla, OO, и т.п. Это очень часто применяется - потому как Unix Way.

Ну а C++ я не обосрал, а очень конкретно и корректно охарактеризовал. Если ты ещё мал, и не понимаешь, почему он - дерьмо, то это легко исправить. Учись, подрастёшь - сам всё узнаешь.

>Ну а C++ я не обосрал, а очень конкретно и корректно охарактеризовал. Если ты ещё мал, и не понимаешь, почему он - дерьмо, то это легко исправить. Учись, подрастёшь - сам всё узнаешь.

Спорить и отвечать на оскорбления я не собираюсь, нервы дороже. А за скрипт спасибо.

Да ты фанатик, однако, раз наезд на C++ воспринимаешь как личное оскорбление...

Посмотри на

gengetopt - skeleton main.c generator

он в общем-то с-шный код генерит. Парсить командную строку и заодно init- файлы. Дешево и сердито.

А на Антихристовского зама не обращай внимания. Это просто его комплексы говорят. Он даже не замечает, когда гадости говорит.

> С виду вроде нормальная, как раз так как я и хотел. Установил
> libboost-dev, а там и намека на program_options нет. Это что ж
> каждому качать прийдется? Да еще и не GPL.

Во-первых, все там есть, ты видимо плохо искал =)

Во-вторых, оно, хотя и не GPL, но AFAIK совместимо. Так что с этим
проблем не вижу.

Чем так плох C++

Приведите конкретные доводы

Всё я уже сделал как посоветовал vsl.

>Во-первых, все там есть, ты видимо плохо искал =) Ну я написал locate program_options и ниче не нашло. Перед этим естественно сделал udatedb.

Ну да ладно, проблема решена всем откликнувшимся спасибо.

Дык данный пример как раз демонстрирует его ущербность - как и ущербность любой другой среды, которая не включает в себя интерпретатор и полноценную рефлексивность. Да, ты лего можешь юзать из C++ какой либо Lua, Python, Guile... Но это будет костыль. Настоящая гибкость появляется, когда в языке есть конструкции read и eval...