v3.5.0

Major API (naming) breaking changes

Important

This is only an API (naming) change. No internal logic was changed.

Format Specifiers

Format in glz::opts are now all caps. This is to disambiguate from structs with similar names.
binary -> BEVE
json -> JSON
ndjson -> NDJSON
csv -> CSV

Important

If you set the format in glz::opts the naming changes from glz::opts{.format = glz::json} to glz::opts{.format = glz::JSON}

to/from specializations

For those who use custom serialization and have specialized to_json<T> and from_json<T>, these have been changed to be more generic. Use to<JSON, T> and from<JSON, T> instead.

This will significantly reduce internal code duplication across formats.

Binary (BEVE) name changes

Glaze used to refer to the BEVE format as binary. This was confusing and would become even more confusing as we add more binary formats.

Pretty much everywhere binary was referred to is now referred to as beve. So write_binary becomes write_beve.

• The file paths glaze/binary have been renamed to glaze/beve
• The header glaze/binary.hpp has been renamed to glaze/beve.hpp

by @stephenberry in #1323

Full Changelog: v3.4.3...v3.5.0

v3.4.3

Internal cleanup and faster hashing

• Length 3 & 4 fast hashes by @stephenberry in #1321
• Improvements to full_flat hashing in #1322

Full Changelog: v3.4.2...v3.4.3

v3.4.2

Internal Improvements

• Internal hashing improvements for BEVE, CSV, stencils, and JSON seeking
  by @stephenberry in #1307, #1309, #1310, and #1311
• Internal tuple handling cleanup in #1312

Full Changelog: v3.4.1...v3.4.2

v3.4.1

Improvements

• New glz::write_at, to write to a target value given a JSON Pointer path by @stephenberry in #1300
• Limit recursive depth in beve_to_json in #1301
• new_lines_in_arrays support for .prettify = true write in #1302
• Enum reading with new hash approach in #1303
• Support for partial writing of const qualified objects in #1304
• Using new hash approach in glz::mustache in #1306

glz::write_at example:

std::string buffer = R"({"str":"hello","number":3.14,"sub":{"target":"X"}})";
auto ec = glz::write_at<"/sub/target">("42", buffer);
expect(buffer == R"({"str":"hello","number":3.14,"sub":{"target":42}})");

Full Changelog: v3.4.0...v3.4.1

v3.4.0

Breaking Change of glz::nameof enum interface

The typical use case of glz::enumerate within a glz::meta has been unaffected, and therefore most users will be unaffected by this change.

This update removes the enum_macro.hpp header (GLZ_ENUM and GLZ_ENUM_MAP) and adds a new glz::meta approach that takes an array of keys and an array of values. This keys/values approach only supports enums in Glaze (currently to support faster internal compilation of enums), but broader support can be added in the future.

The enum_macro approach of using ADL created issues with other repositories that would declare a namespace nameof, and the macro expansion increased compilation time and was not a good, generic solution.

glz::nameof function for internal Glaze enums has been removed.

by @stephenberry in #1297

Other Fixes

• fixes min/max macro conflict in dragonbox.hpp on MSVC by @lambwheit in #1298
• glz::meta keys for enums, removing nameof ADL and enum_macro.hpp

Experimental glz::asio_client changes

• Support asynchronous clients with a socket pool by @stephenberry in #1291

Full Changelog: v3.3.4...v3.4.0

v3.3.4

Experimental glz::repe::registry reworking of locking logic by @stephenberry in #1290

This makes the registry locking logic behave the same for reading and writing. This limits reading a bit more by not allowing asynchronous reads to the exact same field, but it makes asynchronous writing possible, and keeps the locking logic simpler. We can now asynchronously write to differing targets, and importantly we can call asynchronous invocations.

We are removing automatic invoke locking. With variables, there is no place for a user to put logic when it comes to locking/unlocking access. However, when it comes to functions, there is room for users to add mutexes and locks to customize lock behavior. Also, functions often have complex side effects that need to be known to the programmer. On top of this, if we don't manipulate references in an RPC, we'd like the default behavior to be able to asynchronously call these functions. For these reasons we don't automatically lock the path taken to the function call. Because we also don't want to assume that a function call would manipulate the returned state of a data, which would block reads to the data.

Full Changelog: v3.3.3...v3.3.4

v3.3.3

32-bit support

Many thanks to @Bolderaysky for fixing build issues with 32-bit and adding GitHub Action runners to the CI pipeline so that 32-bit support can be maintained. #1287

Fixes

• Fixed error propagation when parsing arrays in glz::beve_to_json by @stephenberry in #1289
• Thanks @pauldreik for reporting

Full Changelog: v3.3.2...v3.3.3

v3.3.2

Fixes

• Fixed key parsing issue with variant object reading of unknown keys by @stephenberry in #1283
• Fixed Apple clang precompiled headers due to std::filesystem::path hashing in #1284

Full Changelog: v3.3.1...v3.3.2

v3.3.1

Fixes

• Fixed lvalue lambda compilation error in corner cases within glz::meta in #1270
• Better validation and excluding trailing whitespace for get_sv_json in #1271
• Additional optional guard to fix compilation on the latest version of MSVC in #1273

Full Changelog: v3.3.0...v3.3.1

v3.3.0

Non-null terminated buffers!

JSON

Non-null terminated buffer reading when using glz::read<glz::opts{.null_terminated = false}>.

In order to not introduce any breaking changes glz::read_json (using default glz::opts) has null_terminated = true.

The default behavior requires null termination for maximum performance.

glz::prettify_json and glz::minify_json also support non-null terminated buffers.

BEVE (binary)

For BEVE we don't care whether a buffer is null terminated anymore, we just always handle the data as if it is not, because we wouldn't get significant performance improvements like we do with JSON. The reason is that a null character is valid binary so we can't make decisions on this value.

What's Changed

• Support for non-null terminated buffers when parsing JSON and BEVE by @stephenberry in #1262

Full Changelog: v3.2.6...v3.3.0