бинарный или текстовый формат?

Текстовые конфиги однозначно лучше, т.к. гуй для их редактирования (текстовый редактор) есть в любой системе.

Если конфиги не особо большие - то однозначно текст. А можно сделать и такие, и такие:) При старте будет читаться текст, если его изменили, и записываться в бинарный формат.

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

Основной аргумент на использование бинарников такой: можно взять какую-нить структуру (struct init {...}), затолкать её в ентот бинарник, потом при старте программы вычитать её же в память, и там начать разгребание. А текстовые нужно парсить, если слишком умный(?) пользователь их "поправит", то нужно обрабатывать ошибки (хотя бинарник тоже можно изуродовать, но текстовик, дескать, открывается просто, и там буквы знакомые встретиться могут, что введёт юзера в искушение...).

>Основной аргумент на использование бинарников такой: можно взять какую-нить структуру (struct init {...}), затолкать её в ентот бинарник, потом при старте программы вычитать её же в память,

Так делать НЕЛЬЗЯ! Вернее можно, но очень осторожно, нужно про __aligned__, про порядок байтов на разных машинах, в итоге гемора будет больще, чем парсить тот же .ini или xml.

>Так делать НЕЛЬЗЯ!

Кроме того такой подход приведёт к конфликту с Гринспуновым 10 правилом.

Ты об этом? "Любая большая система на C или Fortran содержит медленную, плохо продуманную, с кучей ошибок реализацию половины Common Lisp. " Десятое [Других нет] правило Гринспуна "…включая сам Common Lisp." Следствие Морриса

Предполагается использование программы на x86 (может быть, нескоро, на 64-86 архитектуре), переход на Linux - ну, может и соберёмся, если прижмёт, сейчас операционка XP (в основном) или 2000.

А насколько критично, чтобы конфиги быстро читались и парсились? Сколько параметров будет в конфиге?

Ну, пару секунд можем выделить :-), можно и больше. Параметров будет 500 - 1000.

Однозначно текст.

man "Искусство Программирования для Unix" Эрик C. Реймонд

http://www.williamspublishing.com/Books/5-8459-0791-8.html

Преимущества текстовых конфигов:

1)удобное редактирование настроек. в текстовом редакторе все равно удобнее чем через гуй. + есть сразу же средства автоматизации (скрипты), grep, perl, etc...

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

3)переносим - не зависит от аппаратной платформы (порядок байтов и прочее)

4)повторное использование - можно пеенести часть конфига копи-пастом с онойй машины на другую - как это сделать в гуи?

недостаток только - производительность при парсинге.

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

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

Я счас из инета уйду до завтра, а вы продолжайте :-)

А ещё можно использовать готовый API для сохранения настроек, типа gconf или QSettings (вроде так). Для одного есть графическая конфигурялка, для второго текстовый редактор.

Да, это если влом писать свой парсер для конфига.

>Ты об этом

Об этом. Рано или поздно в конфиг захочется добавить что-либо "вычислимое". А для хранения правил вычисления ничего удобнее текста пока не придумали (afaik). Или уже?

в текстовый конфиг можно руками написать комментарий, а это одно из преимуществ.

Ну и в случае текстовым конфигом можно свой парсер не писать :-) И мини-язык не делать: пишем конфиг на С, компилируем при старте программы, затем dlopen и dlsym ^-)))

А еще можно hs-plugins заюзать и писать конфиг на Хаскелле :-))

ЗЫ: вообще в этом случае можно и интерпретатор tcl, perl или python встроить :-)

> Основной аргумент на использование бинарников такой

Нет такого аргумента. Потому что он убивается сразу соображениями переносимости и надежности. Искуроченный пользователем (или случайно попорченный) бинарник починить сложнее, чем текстовик.

Только текст. Если лень самому ваять парсер - взять готовый, их вагон и тележка. Если условия позволяют - xml. Если не хотите, чтобы дурак-пользователь лез туда с кривыми руками - можете текст зазиповать (security through obscurity) - тем самым введете порог на минимальный iq пользователя.

XML, возможно, засевензиппенный

API для XML предостаточно.