LINUX.ORG.RU

JSON в чистом Си

 ,


3

2

Какую библиотеку посоветуете для работы с json в чистом Си? Гугл сходу выдает json-c и jansson. Какая лучше? Или искать третью?

★★★

Последнее исправление: cetjs2 (всего исправлений: 1)

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

wayland_systemd
()

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

waker ★★★★★
()

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

waker ★★★★★
()
Ответ на: комментарий от waker

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от waker

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

Eddy_Em ☆☆☆☆☆
()

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

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

Corey
()
Последнее исправление: Corey (всего исправлений: 1)
Ответ на: комментарий от waker

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Corey

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Corey

ИМХО

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

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

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

Stil ★★★★★
()
Ответ на: комментарий от Corey

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

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

waker ★★★★★
()
Ответ на: ИМХО от Stil

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

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

Stil ★★★★★
()
Ответ на: комментарий от Eddy_Em

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

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от waker

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

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

{
    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
}

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

Corey
()
Последнее исправление: Corey (всего исправлений: 1)
Ответ на: комментарий от Corey

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

buddhist ★★★★★
()
Ответ на: комментарий от Corey

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

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

waker ★★★★★
()
Ответ на: комментарий от Corey

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

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

waker ★★★★★
()
Ответ на: комментарий от quantum-troll

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

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

Corey
()
Ответ на: комментарий от Corey

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

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

схемотично:

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

Deleted
()
Ответ на: комментарий от waker

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

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

Corey
()
Ответ на: комментарий от quantum-troll

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Corey

Ничто не мешает расставить отступы. Твой пример в 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
По мне так вполне читаемо.

quantum-troll ★★★★★
()
Ответ на: комментарий от Corey

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Corey

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

@LAUTERBACH_FLASH_SCRIPT@

??

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Deleted

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

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

Corey
()
Ответ на: комментарий от Deleted

Долго ржал:

        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, число) вместо массива!).

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Corey

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

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.