Glaze 7.2.0

Ваши пейсатели на неведомых языках в погоне на какой-то неведомой херней окончательно головой поехали (ну или так всегда было, или им это ИИ пишет)…

вот смотрю как парсится ISO8601 строка:

   // system_clock::time_point: parse from ISO 8601 string
   // Fast manual parser - no heap allocations, direct character parsing
   template <is_system_time_point T>
      requires(not custom_read<T>)
   struct from<JSON, T>
   {
      template <auto Opts, class It0, class It1>
      static void op(auto&& value, is_context auto&& ctx, It0&& it, It1 end) noexcept
      {
         std::string_view str;
         from<JSON, std::string_view>::template op<Opts>(str, ctx, it, end);

         if (bool(ctx.error)) [[unlikely]]
            return;

         // Minimum: YYYY-MM-DDTHH:MM:SSZ = 20 chars
         if (str.size() < 20) [[unlikely]] {
            ctx.error = error_code::parse_error;
            return;
         }

иду читать стандарт, а там для дат как YYYY-MM-DD так и YYYYMMDD, а для времени допустимо аж 10 вариантов…

это на полном серьезе позиционируется как библиотека, которую можно себе в проект затащить???

а там для дат как YYYY-MM-DD так и YYYYMMDD, а для времени допустимо аж 10 вариантов…

А нужно было читать JSON RFC 8259, в котором вообще нет типа «дата/время».

это на полном серьезе позиционируется как библиотека, которую можно себе в проект затащить???

Конечно.

10 вариантов времени не нужно - одного достаточно.

10 вариантов времени не нужно - одного достаточно.

Unix Time Stamp!

А нужно было читать JSON RFC 8259, в котором вообще нет типа «дата/время».

а что оно тогда парсит? Автор пишет, что ISO 8601:

parse from ISO 8601 string

но судя по всему парсит оно как повезет, поэтому и «быстрое» :)))

а что оно тогда парсит?

То, что самой же библиотекой и сериализовали.

я сейчас аж метрики посмотрел. В проекте 200к строк кода в почти 600 файлах.

Кто-нибудь сходите к этому stephenberry и скажите ему «горшочек, не вари»

предназначенной для чтения и записи JSON

также предоставляет поддержку REPE RPC и сервер и клиент HTTP, […] включая […] поддержку WebSocket и шифрование SSL/TLS.

Ясно-понятно. А носки варить оно умеет?

Зачем? Он их тебе отправит.

Оно же парсит то что само и сериализовало. И сериализует оно время в одном формате (совместимым с ISO8601 в том плане, что софт умеющий ISO8601 должен понять). Зачем им поддерживать 10 форматов.

Пейсал свой парсер json: 2 вечера примерно заняло, конфиги мои парсит и норм. Написано при этом не совсем через джоппу: архитектура у меня такая: сначала сырой текст превращаю в поток событий: список начался, обьект начался, число, строка, двоеточие, список кончился и т.п. А следом этот поток жрётся «понималкой семантики». Например если парсер в состоянии «жду ключ», то приход события отличного от «строка» - это фейл. Разбивка на два этих этапа позволила всё капец как упростить. И никакого yacc/bison и прочего треша-угара. В пару небольших хидеров влезло. Но и рефлексии нет: нах не усралось по-моему: свистоперделка 85 левела, внатуре. Прям обширных тестов у меня нет, го думаю 95% всех нормальных json из реального мира я пожру: ответы от Telegram серваков оно парсит, даже escaping в строках реализовано.

Не помню делал ли я сериализатор, но это проще.

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

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

В проекте 200к строк кода в почти 600 файлах.

Неудивительно, там Claude в контрибуторах.

Оно же парсит то что само и сериализовало

Я конечно код не смотрел, но разве оно не должно парсить чужие JSON'ы? А чужие могут в любом допустимом формате быть.

То, что самой же библиотекой и сериализовали.

Но это лишь частный случай. Чаще всего парсятся чужие джейсоны.

разве оно не должно парсить чужие JSON’ы?

Разве не очевидно, что библиотека заточена на быструю и компактную передачу данных?

А для парсинга любых JSON (и др. форматов) есть более другие библиотеки.

предназначенной для чтения и записи JSON с удобными возможностями сериализации и десериализации данных.

Я не нашел тут упоминания, что оно только для своих JSON. А так возьмешь её для чтения JSON приходящих от клиентов, а оно половину не парсит того что должно по стандарту.

Описание тогда должно звучать как «Библиотека для сериализации и десереализации данных в ограниченное подмножество JSON».

Я не нашел тут упоминания, что оно только для своих JSON. А так возьмешь её для чтения JSON приходящих от клиентов, а оно половину не парсит того что должно по стандарту.

Покажи пример файла, соответствующего ISO/IEC 21778:2017 или ECMA-404, который данная библиотека читает неправильно.

Описание тогда должно звучать как …

Хорошо, исправил.

высокопроизводительной, SIMD-оптимизированной и многопоточной библиотеки Glaze, предназначенной для быстрой сериализации и десериализации данных с поддержкой форматов JSON RFC 8259, …

Неудивительно, там Claude в контрибуторах.

Удивительно!

claude’s Commits
3 commits

Оно же парсит то что само и сериализовало

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

там всего-то 4 байта прочесть нужно

И насколько они human friendly? :)

И насколько они human friendly? :)

ISO8601 считается дружественным к читателю букв, но поделка этого не умеет, несмотря на то, что автор поделки в комментариях декларирует, что умеет, т.е. в явном виде пишет что парсит строку ISO8601 (ну да: leap seconds мы не поддерживаем, а поддержать 31 июня - да почему мы и нет?), однако, даже с весьма ограниченным RFC3339 оно точно так же не справляется.

В сухом остатке: какое нам дело до того, что в поделке от Васяна с тридцаткой лукасов на гитхабе что-то происходит? Оно совершенно никому в таком виде не нужно, а @dataman тупо спамит на нашем любимом LOR.