Зачем чистый С? Может рассмотреть альтернативы? Или специфические требования?

подписался, тоже хотелось бы услышать «за» и «против».

Я использовал json-c. Но с ней поосторожней надо: течь может.

В общем, если тебе серьезно надо, то лучше свое напиши. Все равно тебе ведь не нужно общую поддержку! Только частную же.

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

Eddy, а мне вот кажется что jansson вполне вменяемый, и писать свое нет смысла. документация приятная, сборка простая (просто все C-файлы вкинуть в проект), и т.п.

Вполне возможно. Просто когда я выбирал, jansson вообще был никакой.

По-диагонали глянул API jansson — вроде бы те же яйца, что и json-c.

Кстати, можно вообще на макросах или своей прокладке реализовать поддержку обеих. И в зависимости от того, что у юзера установлено, cmake будет активировать те или иные макросы. Если ни той, ни другой — сообщать об ошибке.

ну если тебе такое нужно - то так и делай. я просто нужные либы в проект включаю.

Может, не совсем релевантно к вопросу ОПа, но все же спрошу здесь - а есть ли профит использовать json в качестве формата конфигурационных файлов в проектах на с и с++? Недавно возникал вопрос о том, какой простенький язык для описания иерархических структур выбрать. Пока что остановились на б-гомерзком yaml-e, но поскольку решение было написано на коленке в качестве временной затычки, есть шанс, что вскоре этот вопрос поднимется снова.

Json мне сердцу милее, но смущает то, что формат не предусматривает комментариев внутри файла.

Я обычно для себя делаю, поэтому чаще всего мне лень. Если я где-то делаю зачатки "универсальности", то лишь оттого, что нужно бывает запускать код и на древнем железе.

Смотря что за конфиги у тебя. Мне за глаза хватает "ini-формата" (типа "переменная=значение"), а еще бинарными конфигами пользуюсь, если нет нужды вручную их править. JSON нужен лишь в случае сложных структур данных.

А jansson не может течь? Внешне то оно неплохо выглядит, но могут быть подводные камни.

не знаю. я не пользовался пока.

ИМХО

а есть ли профит использовать json в качестве формата конфигурационных файлов в проектах на с и с++? Недавно возникал вопрос о том, какой простенький язык для описания иерархических структур выбрать.

иерархических структур

если хватает json, то json, иначе xml

а есть ли профит использовать json в качестве формата конфигурационных файлов в проектах на с и с++?

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

я чето потерял нить. что именно тебе лень?

Судя по табличке отсюда http://lionet.livejournal.com/118853.html у jansson последователей больше.

XML — вообще говно, а не формат. Если нужно, чтобы человек мог читать/править, то выбор очевиден: INI или JSON; если не нужно — бинарный конфиг. XML — говнище, которое ни человеку, ни машине не нужно!

Универсальную поддержку делать лень. Делаю только для какой-нибудь одной библиотеки — и все.

JSON — подмножество YAML

Если нужно, чтобы человек мог читать/править

то делается нормальная графическая конфигурялка и пользователю вообще не надо лезть ни в какие конфиги.

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

графическая конфигурялка

УБИВАТ!!!

Ну, скажем, числодробилки есть смысл затачивать параллельно под CUDA и OpenMP: вдруг кто-то запустит ее на компьютере без видеокарты, либо со слабой видюхой?

а поддержка 2 json парсеров там зачем?

Смотря что за конфиги у тебя

Что-нибудь типа такого:

{
    flasher: {
        type: "lauterbach",
        scripts: {
            flash: "@LAUTERBACH_FLASH_SCRIPT@",
            verify: "@LAUTERBACH_VERIFY_SCRIPT@",
            test: "@LAUTERBACH_TEST_SCRIPT@"
        }
    },
    cameras: [{
        ip: "192.168.1.110",
        tty: "/dev/ttyS0",
        flasherPort: 20000
    }, {
        ip: "192.168.1.111",
        tty: "/dev/ttyS1",
        flasherPort: 20001
    }, {
        ip: "192.168.1.112",
        tty: "/dev/ttyS2",
        flasherPort: 20002
    }, {
        ip: "192.168.1.113",
        tty: "/dev/ttyS3",
        flasherPort: 20003
    }],

    applicationBinaryPath: "@CAMERA_APPLICATION_BINARY_PATH@",
    bootloaderBinaryPath: "@CAMERA_BOOTLOADER_BINARY_PATH@",
    calibrationDataPath: "@CAMERA_CALIBRATION_DATA_PATH@",

    testDuration: 240
}

И да, это люди будут править руками.

Разметку текста тоже в JSON будешь делать?

https://github.com/toml-lang/toml
Можешь не благодарить.

JSON — подмножество YAML

Это хорошо или плохо?

Это факт. Просто у вас в сообщении эти сущности несколько противопоставляются

А вдруг одна из библиотек станет deprecated?

Json мне сердцу милее, но смущает то, что формат не предусматривает комментариев внутри файла.

нуууууу.. практически все парсеры умеют JSON5, не? а он поддерживает комменты, barewords, и тп.

Я бы велосипед сделал. Это будет проще, чем трахаться с чужим парсером JSON, а потом еще в свой формат переводить...

А вдруг одна из библиотек станет deprecated?

ну да, это конечно определяющий фактор при решении написать 100500 бакендов ко всему в своей поделке.

TeX/LaTeX, ясен пень. А к чему это?

использовать огромный набор тьюринг-полных костылей для среднепростой разметки.

https://github.com/toml-lang/toml

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

смущает то, что формат не предусматривает комментариев внутри файла.

по замыслу разработчиков - json это именно формат данных, а не конфигов, поэтому предлагается использовать прослойку перед парсером json для убирания коментариев (и другой чистки, например CLRF). см. JSMin

схемотично:

cat file.conf | JSMin | json-парсер 

практически все парсеры умеют JSON5, не?

Не, я постоянно обламываюсь, когда забываю взять в кавычки ключи, например. Curl точно на это ругается. А о комментариях знают, думаю, и того меньше библиотек.

Я бы велосипед сделал

:)

Мне понравился http://zserge.com/jsmn.html

Дык, для README-файлов, ясен пень, никаких латехов не надо: табуляциями и пробелами форматируй себе на здоровье.

А если подразумевается печать или чтение в нормальном виде — только латех.

Ничто не мешает расставить отступы. Твой пример в toml будет выглядеть так:

[flasher]
type = "lauterbach"

    [flasher.scripts]
    flash = "@LAUTERBACH_FLASH_SCRIPT@"
    verify = "@LAUTERBACH_VERIFY_SCRIPT@"
    test = "@LAUTERBACH_TEST_SCRIPT@"

[[cameras]]
ip = "192.168.1.110"
tty = "/dev/ttyS0"
flasherPort = 20000

[[cameras]]
ip = "192.168.1.111"
tty = "/dev/ttyS1"
flasherPort = 20001

[[cameras]]
ip = "192.168.1.112"
tty = "/dev/ttyS2"
flasherPort = 20002

[[cameras]]
ip = "192.168.1.113"
tty = "/dev/ttyS3"
flasherPort = 20003

applicationBinaryPath = "@CAMERA_APPLICATION_BINARY_PATH@"
bootloaderBinaryPath = "@CAMERA_BOOTLOADER_BINARY_PATH@"
calibrationDataPath = "@CAMERA_CALIBRATION_DATA_PATH@"

testDuration = 240

А у меня и так все на велосипедах. Скажем, те же CGI: вменяемых средств для работы с вебом я в интернете не нашел, поэтому навелосипедил свое.

[troll-mode]systemd-unit конфиги лучше сделать, вот парсер: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/unit.c [/troll-mode]

Кстати, что значит подобное:

@LAUTERBACH_FLASH_SCRIPT@

??

Если значение переменной, то почему не $LAUTERBACH_FLASH_SCRIPT? Ведь вообще непонятно же!

поэтому предлагается использовать прослойку перед парсером json для убирания коментариев

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

Долго ржал:

        if (c->std_output != EXEC_OUTPUT_KMSG &&
            c->std_output != EXEC_OUTPUT_SYSLOG &&
            c->std_output != EXEC_OUTPUT_JOURNAL &&
            c->std_output != EXEC_OUTPUT_KMSG_AND_CONSOLE &&
            c->std_output != EXEC_OUTPUT_SYSLOG_AND_CONSOLE &&
            c->std_output != EXEC_OUTPUT_JOURNAL_AND_CONSOLE &&
            c->std_error != EXEC_OUTPUT_KMSG &&
            c->std_error != EXEC_OUTPUT_SYSLOG &&
            c->std_error != EXEC_OUTPUT_JOURNAL &&
            c->std_error != EXEC_OUTPUT_KMSG_AND_CONSOLE &&
            c->std_error != EXEC_OUTPUT_JOURNAL_AND_CONSOLE &&
            c->std_error != EXEC_OUTPUT_SYSLOG_AND_CONSOLE)
                return 0;

Что за индус это писал? Или китаец? Китайцы тоже копипасту любят (посмотрел бы ты их "библиотеки" для работы с LCD на STM32, там чуть ли не по сотне строк типа write_reg(reg, число) вместо массива!).

для конфигов в своем проекте можно же подобрать библиотеку, которая умеет JSON5. я использую и в ноде, и в perl. коллега юзает в C#. уверен, что и для сишечки можно что-то накрутить.

Это типичный код systemd. С кучей повторов и передозом GOTO.