LINUX.ORG.RU

Glaze 4.3.0

 , , , ,


1

3

6 января состоялся выпуск 4.3.0 одной из самых быстрых библиотек чтения и записи JSON, написанной на языке C++ (header-only, стандарт C++23) и распространяемой по лицензии MIT.
Также поддерживаются форматы CSV и BEVE.

Список изменений:

  • Добавлена compile-time опция (и враппер) append_arrays, которая добавляет данные к типам, подобным std::vector без их перезаписи:
std::vector<int> v{};
constexpr glz::opts append_opts{.append_arrays = true};
expect(not glz::read<append_opts>(v, "[1,2,3]"));
expect(v == std::vector<int>{1,2,3});
expect(not glz::read<append_opts>(v, "[4,5,6]"));
expect(v == std::vector<int>{1,2,3,4,5,6});
  • Добавлена поддержка динамически изменяемых типов библиотеки Eigen.
  • Добавлена поддержка рефлексии векторных типов Eigen.
  • Улучшена glz::async_string с большим количеством методов и поддержкой std::format.
  • Рефакторинг записи map.
  • Исправление always_null_t в работе с объектами и более быстрая запись всегда null.
  • Более эффективные числовые ключи в динамических map.

>>> Список изменений версии 4.3.0 на GitHub

★★★★★

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

header-only

Господа, я совершенно далек от разработки на C++ (хоть и понимаю суть термина). Хотелось бы услышать мнение хардкорных плюсовиков, которые используют последние стандарты: это рак или топчик?

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

это рак или топчик?

Иногда необходимость. Те же Eigen или GLM будут использовать разный код, в зависимости от -march=.

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

если использовать всякие шаблоны, то ничего кроме header-only в принципе не может быть, потому что это вычисления во время компиляции. А если не использовать, то это уже получается не C++, а Си с классами.

В целом это трейд-офф. Если тебе важна скорость работы, то используй header only, шаблоны и вот это все. Если важны скорость компиляции, размер бинарника, возможность что-то засунуть в отдельную so-шку и независимо ее обновлять - то используй обычный Си с классами, с наследованием, виртуальными методами и т.п., они никуда не делись.

Лично мое мнение - все эти парсеры жсон более-менее бесполезны до появления C++26 со статической рефлексией, которая позволит сделать нормальный апи. И вообще, прежде чем бросаться парсить жсон, надо сначала посмотреть, а нужен ли он тут в принципе.

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

если использовать всякие шаблоны, то ничего кроме header-only в принципе не может быть, потому что это вычисления во время компиляции. А если не использовать, то это уже получается не C++, а Си с классами.

Если быть совсем занудным, то в принципе может быть.

  1. Вполне можно использовать темплейты объявленные в хедере, а определённые+инстанциированные в cpp файле, если все нужные типы известны заранее.

  2. Можно использовать локальные темплейты созданные в cpp файле.

Но согласен, это сильно сужает область применения.

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

это рак или топчик?

Хидеры ради хидеров.

Хидер-онли библиотеки по сути вендорлок на С++, лично мне с таким подходом не по пути.

Зиг конечно традиционно хидер-онли будет понимать и компиллировать, но лучше, имхо, наоборот писать на С++ в том стиле, чтобы потом любой программист смог в полуавтоматическом режиме переписать код с С++ на Зиг. Метапрограммирование на Зиге натуральное и естественное.

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

Приятно, когда пишешь статически линкуемое приложением, но когда у тебя линкуется и так сто библиотек, то лишь замедляет компиляцию

SL_RU ★★★★
()

JSON не нужен.

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

Смешно, да. Потому что yyjson, написанный на ANSI C, парсит быстро, а C++23 тут абсолютно не причем. Но авторы будут с пеной у рта доказывать, что оно такое быстрое, потому что C++23 с какими-нибудь compile-time вычислениями и прочим.

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

Да либа маленькая, к тому же на ANSI C написанная. Она компилироваться будет быстро. А от какого-нибудь не header-only Boost C++ libraries проблем со сборкой и временем компиляции гораздо больше, хотя Boost последнюю ценность потерял, когда отказался от поддержки C++03, он стал просто бесполезен, это было чуть ли не единственное его полезное свойство.

zx_gamer ★★★
()

самых быстрых библиотек

К че-е-е-м-у-у та-а-к-а-а-я спе-е-ешка-а-а, господа-а-а-а…

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

С++ не умеет разворачивать шаблоны за пределами места их объявления, поэтому если у тебя есть шаблонный класс, тебе придется все шаблонные методы реализовывать там же.

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

У нас был отдельный сборочный сервер с настроенным distcc.

LongLiveUbuntu ★★★★★
()

Парочка вопросов:

  1. Поддерживается JSONC, aka «JSON + Comments»?
  2. При записи есть возможность сохранять очерёдность ключей? Иными словами, прочитал файл, изменил значения, записал: будет фарш или старые ключи останутся на своём месте, новые добавятся в конце секций?
hatred ★★★
()
Последнее исправление: hatred (всего исправлений: 1)

одной из самых быстрых библиотек чтения и записи JSON

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

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

Прематур вот это всё

Для mvp прото json лингва франка

Трудность оптимальности момента рефакторинга

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

лучше, имхо, наоборот писать на С++ в том стиле, чтобы потом любой программист смог в полуавтоматическом режиме переписать код с С++ на Зиг.

С какого перепугу я должен страдать ради того чтобы какому-то переписывателю на очередной недоязычок стало проще переписывать?

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

С какого перепугу я должен страдать ради того чтобы какому-то переписывателю на очередной недоязычок стало проще переписывать?

Ох лол. То есть с С++ шаблонами писать это не страдания, а зиг-френдли код писать — страдания.

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

не надо использовать JSON

Когда выбора нет, то парсят то, что дают.

dataman ★★★★★
() автор топика
Ответ на: комментарий от hatred
  1. Поддерживается JSONC, aka «JSON + Comments»?
struct opts {
  uint32_t format = json;
  bool comments = false; // Support reading in JSONC style comments
  1. При записи есть возможность сохранять очерёдность ключей?

Не знаю, надо пробовать.

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

Потому что yyjson, написанный на ANSI C, парсит быстро, а C++23 тут абсолютно не причем.

У тебя какая-то каша в голове получилась. yyjson - это парсер у reflect-cpp. У reflect-cpp С++20, и нужен он не для парсера, а для рефлексии. И да, yyjson/reflect-cpp не самый быстрый.

У glaze, насколько я понимаю, своя собственная реализация парсера json, и она уже на C++23 (хотя сам парсер вряд ли этого прям сильно требует, в основном 23 нужен опять же для рефлексии). yyjson к glaze не имеет отношения. Но glaze я не тыкал, так что м.б. в чём-то не прав.

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

То есть с С++ шаблонами писать это не страдания

Нет, не страдания.

зиг-френдли код писать — страдания

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

Мотивация таких адептов предельно ясна: они хотят, чтобы люди вокруг писали код, который они смогут воровать и выдавать за свой с наименьшими усилиями.

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

Потому что адепты-переписыватели не осилили своровать код как есть, и оказались вынуждены переписывать вручную? Не вижу никакой связи.

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

для заведомо более немощного языка

для заведомо более немощного языка

для заведомо более немощного языка

для заведомо более немощного языка

В этом немощном языке рефлексия как тучу лет.

sarumeister
()
Последнее исправление: sarumeister (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.