Вышел parse_conf 1.0pre

> Формат вовсе не "yet another".

Именно что yet another.

Просто живет не в одной конкретной программе, а его выделили в библиотеку.

Сейчас нет возможности подробно ответить. Но дело не только в возможности не набирать несколько раз одно и то же.

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

Кстати, в Питоне ConfigParser имеет такую фичу и используется эта фича именно в этом контексте очень часто.

Возможны и другие приложения, но это, имхо, основные. По крайней мере я их использую.

А заниматься конкатенацией строк в программе, вместо того, чтобы концентрироваться на алгоритме - это тоже не правильно, ИМХО (это я отвечаю на другой пост об этом же самом).

> Именно что yet another.

> Просто живет не в одной конкретной программе, а его выделили в библиотеку.

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

В свое время я не хотел писать библиотеку, но найти подходящего готового ничего не смог. А надо всего-то чтобы было 4 функции: читать файл, писать файл, занести строку и получить строку, а все что лишнее - это от лукавого. Но варианты были либо что-то вроде libconfig с тыщей функций и непонятным форматом, который ничуть не лучше xml. Уж лучше лисп, тогда. Либо совсем что-то убогое. Захотелось написать (напоминаю, в 2002 году, сравните с датами других библиотек). А потом и выложить - вдруг еще есть такие, кому надо именно это. :)

Забыл добавить, что писать разрешение ссылок было прикольно. Надо было придумать и решить туеву хучу всяких мелочей типа разрешения рекурсии, или игр с памятью, или как увязать глобальные ссылки с инкрементом значений (в библиотеке этой есть += для переменных, кстати, есть также и перенос строк) и это было весело. Ну, а если это кому-то еще пригодится - вообще супер тогда :)

Замечание чисто по стилю кодирования. Вы используете имена типов pcnf_t, record_t, gholder_t, и т.п. Вы, конечно, вправе называть типы как вам угодно, но имена с _t на конце - не православны, т.к. зарезервированы для POSIX. http://www.gnu.org/software/libtool//manual/libc/Reserved-Names.html

>Сделать очень легко, но разве это нужно?

Иногда удобно. Например часть конфига комментить не построчно, а сразу блоком.

> Замечание чисто по стилю кодирования. Вы используете имена типов pcnf_t, record_t, gholder_t, и т.п. Вы, конечно, вправе называть типы как вам угодно, но имена с _t на конце - не православны, т.к. зарезервированы для POSIX. http://www.gnu.org/software/libtool//manual/libc/Reserved-Names.html

Гм, а я честно говоря и не знал про такое. Первая реакция на прочтенное было "чот они много хотят". Однако насколько могу судить большинство или тоже не знают или положили на это "большой и толстый". Вот передо мной сырцы BIND и там сплошь и рядом эти нарушения с "_t" да и не только там, много где. Может POSIX не православен? :)

>делать очень легко, но разве это нужно?

Вообщето коментарии в конфигах маст би.

# aaa может быть value1, value1 или value1

key = value1

"Я че все должен помнить?"

>и это - задача проги (а не админа) - складывать их вместе?

Эта задача проге может быть неизвеста. Атрибут в конфиге может быть вообще синтетическим - то есть проге не интересным. НАпример:

data_home = /my/data/home
data_config=${data_home}/data.conf
access_config=${data_home}/access.conf

Это дает возможность гибкой натройки. А то что ты предложил просто выносит данные в специфичной модели наружу которую поменять нельзя.

>А сложность - внутри программы.

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

>Пусть создатели хмл убьют себя об стену.

Есть еще такие странные вещи именуемые программами которые хотят ковырятся и главное _писать_ такие конфиги. И писатели таких програм предложат убиться об стену сочинителям нерегулярных текстовых конфигов:)

Уж не говоря о том что в приведенном конфиге для лог4ж семантика строк неочевидна из-за отстутствия очевидной группировки которая там есть. То есть XMLный конфиг log4j можно легко понять, а текстовый надо просто знать.

>А теперь затрём один симбол. Если затёрта скобка в хмл - п^Щсливай воду. В первом-же файле - менее 1% букв - критические для работы.

ПРи чем весьма ясно почему - парсер грамотно ругнется. А у тебя будет "программа запускается а эта херня почему-то не работает - почему сиди разбирайся" - и то что проблема в конфиге еще вычислить надо.

Валидировать конфиги и читать их строго - весьма желательно.

списки и мапы поддерживаются?

> списки и мапы поддерживаются?

Нет. И я не вижу смысла. В таком случае действительно лучше пользуйте libconfig.

А комментарии конечно поддерживаются. Но только не сишные, а стандартные ини-файловые. Все что полсе # или ; отчекается (понятно, елси они не в строке или не \; \#)

> Замечание чисто по стилю кодирования. Вы используете имена типов pcnf_t, record_t, gholder_t, и т.п. Вы, конечно, вправе называть типы как вам угодно, но имена с _t на конце - не православны, т.к. зарезервированы для POSIX.

Спасибо. Интересно. Но я привык видеть _t в конце новых типов. Мне кажется резервирование такого рода некорректно. Можно вообще весь алфавит зарезервировать. Достаточно имен с подчеркиваниями в начале.

Посмотрел... Нет, то что там рекомендуется - это перебор. Включая и многое остальное.

>data_home = /my/data/home
>data_config=${data_home}/data.conf
>access_config=${data_home}/access.conf

Очень опасный путь - вводить переменные, т.е. запутывать конфиги.
Ты даёшь возможность админу-путаннику всё на свете запутать и запутать других.
(Если одно значение меняется - это не должно приводить к второстепенным эффектам. Нет дебаггера конфига).
По-хорошему - пути должны быть всегда независимыми (так как в этом - гибкость конфигурации), то-есть прога должна разрешить писать
и
data_config=/my/data2/home/data.conf
и
data_config=data.conf
а то что во втором случае будет использоваться дефолтовый data_home - должно быть описано в комментарии.

Ненормализованный конфиг - по крайней мере для меня - это плохое качество программы/лень программиста.

В твоём примере - _дополнительные_ возможности ошибок, которых можно избежать, сделав больше гибкости внутри программы

> Должно быть просто и там и там - то есть средне. Иначе будешь вместо грамотного конфигурирования зханиматься грамотным преписыванием.


Не согласен.
Программер должен трудиться до тех пор - пока не сделает _максимально_ возможный простой (для данного домейна бизнес-терминов) интерфейс с юзером, желатеьно одну кнопку. Если нужна конфигурабельность - она должна быть максимально проста, без зависимостей, идеально - в виде правил. И ассоциативные пары ключ-значение - достаточный механизм для выражения чего угодно. (В ИИ хеш хешей - фреймы - несут вообще всё что угодно). А хеш-хешей всегда можно однозначно раздробить на плоскую хеш (конфиг) - за счёт значимых имён и их описаний (описания - комментарии - на человеческом, CNF-языке;)

> Нет дебаггера конфига).

Есть дебаггер. Он вместе с библиотекой, называется pcnfdump.

С остальным несогласен совершенно. Кесарю кесарево, а конфигу - конфигово. Нефига, короче, каждую программу перегружать размышлениями о гибкости чтения начальных данных.

> Если нужна конфигурабельность - она должна быть максимально проста, без зависимостей, идеально - в виде правил.

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

>Уж не говоря о том что в приведенном конфиге для лог4ж семантика строк неочевидна из-за отстутствия очевидной группировки которая там есть.

какая ещё нужна группировка? (в имёнах ключей - аналог namespaces - все та-же, даже более сконденсированная информация - группировки более чем достаточно).


> То есть XMLный конфиг log4j можно легко понять, а текстовый надо просто знать.

несогласен. Для меня - наоборот. В хмл надо знать дополнительные сущности-ради-сущностей, происходящие от натягивании IPC-технологии на глаз^Wобласти где она неприменима, в данном случае- на конфиги.

Что-то вдруг подумалось: блин, насколько с переменными конфиг становится ЯСНЕЕ.

> Есть дебаггер. Он вместе с библиотекой, называется pcnfdump.

тогда это не конфиг, а язык программирования. И админа надо перезвать в программиста. И вообще - почему на Ц не писать тогда - гораздо более гибко будет. Конфиг должен быть прост как яй^Wнабор переданных через аргументы значений (те-же самые вещи нужно иметь возможность передать через ключи, т.е. значения должны быть простыми токенами)

>Что-то вдруг подумалось: блин, насколько с переменными конфиг становится ЯСНЕЕ.

Для данного человека, который пишет - да.
А для другого - нужно лазить по файлу, искать референсы (если менять - надо знать - кто свалится) итд. С парой-тройкой индирекшенов - легко отстрелить ногу (не себе конечно, а тому прогр^Щадмину, который будет всё раскручивать - если редактирующих много, добавляли изменения много лет, потом уходили).

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

Посмотрел на библиотеку - ссылки (макроподстановки) - вещь конечно полезная (кому не нравится - пользоваться никто не заставляет!). Сам пользуюсь конфигами в виде ini-файлов и в предлагаемой библиотеке лично мне не хватает значений по умолчанию в функциях получения значения поля. Очень мне лениво проверять каждое поле на существование в конфиге!

> и в предлагаемой библиотеке лично мне не хватает значений по умолчанию в функциях получения значения поля.

+1 Будет в версии 1.0, и в течение пары дней в репозитории. Спасибо.

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

Автор, мне нравится Ваша библиотека, хочу использовать, но сперва, ткните меня тупого и невнимательного носом: как с помощью этого API получить список всех секций имеющихся в конфиг файле?

> Автор, мне нравится Ваша библиотека, хочу использовать, но сперва, ткните меня тупого и невнимательного носом: как с помощью этого API получить список всех секций имеющихся в конфиг файле?

Вы не невнимательны, такого в АПИ нет. Можно получить список, но не напрямую. Прежде чем я это сделаю, мне важно понять, в каком виде нужен список всех секций? В виде какого объекта?

Например, я могу предложить функцию, которая выдаст число имеющихся секций, и другую, которая будет выдавать имена секций по номеру. Можно какой-то объект придумать. Сейчас можно получить список как ABL список. Но в таком виде не выглядит разумно. В общем, посоветуйте, а я реализую.

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

Этого будет вполне достаточно. Если сделаете, то, возможно, будет еще одно некое тестирование/применение Вашей библотеки в реальной системе.

Когда примерно?

Сегодня-завтра будет в репозитории на sourceforge. Обязательно будет в версии 1.0 (конец следующей недели). Кстати, будет ли полезно выдавать список переменных в секции?

Сделал такой интерфейс:

Первая функция pcnf_section_names инициализирует список имен и возвращает число секций, включая глобальную NULL-секцию.

Вторая функция pcnf_section_name_next возвращает имя секции, все время
 следующее, пока не вернет NULL, начальная глобальная секция не 
возвращается, по очевидным причинам. Она всегда присутствует и ее имя 
NULL.

Чтобы распечатать все секции надо будет, например, написать такой код:

  pcnf_section_names( pcnf );
  char* sname;
  while ( sname = pcnf_section_name_next(pcnf) ) 
      printf("Section name: %s\n", sname);


Ограничение: результат pcnf_section_name_next гарантируется только 
если в промежутках между вызовом section_names и section_name_next не 
было вызовов других функций библиотеки.

Это пойдет?

Первый вариант сделать проще, но уж больно не хочется из-за n^2 
эффективности в случае цикла по всем секциям.

Все таки вернулся к первому варианту. Не хочется side-effects.

> Кстати, будет ли полезно выдавать список переменных в секции?

да, может пригодиться. Буду ждать релиза.