mirror of
https://github.com/nlohmann/json.git
synced 2026-09-28 18:50:31 +00:00
* Support zero-member types in NLOHMANN_DEFINE_TYPE_* macros (#4041) NLOHMANN_DEFINE_TYPE_INTRUSIVE(Type) and its 11 sibling macros produced broken code for types with no members to serialize. Invoking a variadic macro so __VA_ARGS__ is empty is only standard-conforming since C++20, so a plain __VA_OPT__ fix (as tried in #5142) breaks every pre-C++20 build under -pedantic. Instead, make all 12 macros purely variadic and dispatch on argument count using a sentinel-padded extension of the existing NLOHMANN_JSON_GET_MACRO idiom, giving full C++11-C++26 support with no feature-test gate. Verified against real GCC 16 and Clang at -std=c++11/14/17/20 with -pedantic -Werror -Wvariadic-macros: zero regressions in the existing unit-udt_macro.cpp suite plus 12 new zero-member test cases. Signed-off-by: Niels Lohmann <mail@nlohmann.me> * Fix CI failures in zero-member NLOHMANN_DEFINE_TYPE_* macros Three issues surfaced on PR #5272's real CI that weren't caught by local testing against a narrower flag set: - GCC -Werror=noexcept: the four truly-empty from_json bodies (plain INTRUSIVE/NON_INTRUSIVE, with and without _WITH_DEFAULT) provably never throw but weren't declared noexcept; mark them noexcept explicitly. to_json and the derived-type from_json overloads are left alone since they genuinely can throw (object assignment / delegating to the base class's from_json). - clang-tidy bugprone-macro-parentheses: false positive on the same 8 zero-member bodies (Type/BaseType used purely as declarator types); suppressed with NOLINTNEXTLINE comments in the same style already used elsewhere in this file (see NLOHMANN_JSON_SERIALIZE_ENUM). - MSVC's traditional preprocessor doesn't fully expand NLOHMANN_JSON_CAT(prefix, NLOHMANN_JSON_TYPE_TAG(...))(...) in one pass, which broke a pre-existing one-member usage in unit-regression2.cpp with syntax errors. Wrap all 12 public dispatcher macros in an extra outer NLOHMANN_JSON_EXPAND(...), matching the pattern NLOHMANN_JSON_PASTE already uses for the same MSVC quirk. Re-verified against real GCC 16 and Clang at -std=c++11/14/17/20 with -pedantic -Werror -Wvariadic-macros -Wnoexcept, including the exact files that failed in CI (unit-udt_macro.cpp, unit-regression2.cpp), against both the modular headers and the re-amalgamated single header. Signed-off-by: Niels Lohmann <mail@nlohmann.me> * Fix clang-tidy misc-const-correctness in unit-udt_macro.cpp The four zero-member ONLY_SERIALIZE test objects are only ever read (via to_json), never mutated, so mark them const per clang-tidy. Signed-off-by: Niels Lohmann <mail@nlohmann.me> * Fix derived-type macro dispatch capping members at 62 instead of 63 NLOHMANN_JSON_GET_MACRO resolves 64 positional arguments, with NAME at position 65. NLOHMANN_JSON_TYPE_TAG dispatches on Type plus the member list, so it resolves correctly up to the 63 members NLOHMANN_JSON_PASTE supports. NLOHMANN_JSON_DERIVED_TYPE_TAG dispatched on the two-token Type,BaseType prefix plus the member list, running out one slot early: at 63 members, position 65 landed on the last member name instead of a sentinel and NLOHMANN_JSON_CAT built an undefined identifier such as NLOHMANN_JSON_DEFINE_DERIVED_TYPE_INTRUSIVE_m63, with the compiler reporting "unknown type name 'm1'" once per member and nothing pointing at an argument-count limit. That silently reduced all six NLOHMANN_DEFINE_DERIVED_TYPE_* macros from 63 members to 62, contradicting the "up to 63 members" contract in docs/mkdocs/docs/api/macros/nlohmann_define_derived_type.md. Drop the leading Type and defer to NLOHMANN_JSON_TYPE_TAG so the tag is computed from BaseType plus the member list, which fits the available slots. The zero-own-member derived bodies are therefore selected by tag 1 rather than 2, and the sentinel table for the derived tag is no longer needed. Add a regression test at the documented maximum for both the plain and the derived macros; it fails to compile against the previous dispatch. Signed-off-by: Niels Lohmann <mail@nlohmann.me> * Name the zero-member macro bodies by intent, not argument count The dispatch tag was the literal token 1 or N, pasted onto a macro prefix to select the zero-member or member-carrying body. For the derived-type macros that reads wrong: their tag is computed after dropping the leading Type, so the zero-member body was named _1 while taking two parameters (Type, BaseType). Emit EMPTY and MEMBERS instead. The mechanism is unchanged -- the tag is still a token pasted onto the prefix by NLOHMANN_JSON_CAT -- but the body names now say what they are rather than encoding an argument count that only lines up for half of the macros. Collapse the four duplicated zero-member bodies while here: with no members there is nothing to default, so each _WITH_DEFAULT_EMPTY body was a byte-for-byte copy of its plain counterpart. They are now one-line aliases, leaving a single definition of what an empty object serializes to per intrusive/non-intrusive and base/derived combination. No functional change: for both zero-member and member-carrying types the preprocessed to_json/from_json output is token-for-token identical, and the arity limits are unchanged (63 members, base and derived). Signed-off-by: Niels Lohmann <mail@nlohmann.me> * Document zero-member support in the macro API reference docs/mkdocs/docs/features/arbitrary_types.md already gained a note, but the three api/macros pages are where the parameter contract is actually specified and they still described member as a non-empty list. State that the list may be empty on each page, and add a note showing what the zero-member case generates: an empty JSON object for the plain macros, and base-type-only serialization for the derived ones. Both notes record that the WITH_NAMES variants do not support this. Signed-off-by: Niels Lohmann <mail@nlohmann.me> * Keep user macros named EMPTY or MEMBERS out of the member-count dispatch The dispatch produced the bare token EMPTY or MEMBERS and pasted it onto the macro prefix afterwards. In between, the token was rescanned, so a user macro with either name replaced it: with `#define MEMBERS x` in scope, even NLOHMANN_DEFINE_TYPE_INTRUSIVE(A, member) -- which compiled before -- expanded to garbage, and `#define EMPTY` broke the zero-member form. Paste the suffix onto the prefix directly in the GET_MACRO slot table instead. Operands of ## are not macro-expanded, so the selected body name is formed before any user macro can interfere. NLOHMANN_JSON_TYPE_TAG and NLOHMANN_JSON_DERIVED_TYPE_TAG become NLOHMANN_JSON_TYPE_BODY and NLOHMANN_JSON_DERIVED_TYPE_BODY, taking the prefix as their first argument; NLOHMANN_JSON_CAT is no longer needed. The body macro names are unchanged, and so is the generated code. Add a regression test that defines EMPTY and MEMBERS around plain and derived types, with and without members. Signed-off-by: Niels Lohmann <mail@nlohmann.me> * Test for EMPTY and MEMBERS so -Wunused-macros accepts them Signed-off-by: Niels Lohmann <mail@nlohmann.me> --------- Signed-off-by: Niels Lohmann <mail@nlohmann.me>
This commit is contained in:
Niels Lohmann
@@ -57,7 +57,8 @@ Summary:
|
||||
: name of the base type (class, struct) `type` is derived from
|
||||
|
||||
`member` (in)
|
||||
: name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated list
|
||||
: name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated
|
||||
list, which may also be empty
|
||||
|
||||
## Default definition
|
||||
|
||||
@@ -127,6 +128,20 @@ void to_json(BasicJsonType& j, const B& b) {
|
||||
- Macros 4, 5, and 6 have the same prerequisites of [NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE](nlohmann_define_type_non_intrusive.md).
|
||||
- Serialization/deserialization of base types must be defined.
|
||||
|
||||
!!! info "Derived types without own members"
|
||||
|
||||
The member list may be empty. The macro then generates a `to_json`/`from_json` pair that only delegates to
|
||||
the base type, so `type` serializes exactly like `base_type`:
|
||||
|
||||
```cpp
|
||||
struct derived : base
|
||||
{
|
||||
NLOHMANN_DEFINE_DERIVED_TYPE_INTRUSIVE(derived, base)
|
||||
};
|
||||
```
|
||||
|
||||
The `WITH_NAMES` variants do not support this.
|
||||
|
||||
!!! warning "Implementation limits"
|
||||
|
||||
See Implementation limits for [NLOHMANN_DEFINE_TYPE_INTRUSIVE](nlohmann_define_type_intrusive.md) and
|
||||
|
||||
@@ -33,7 +33,8 @@ Summary:
|
||||
: name of the type (class, struct) to serialize/deserialize
|
||||
|
||||
`member` (in)
|
||||
: name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated list
|
||||
: name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated
|
||||
list, which may also be empty
|
||||
|
||||
## Default definition
|
||||
|
||||
@@ -58,6 +59,20 @@ See the examples below for the concrete generated code.
|
||||
|
||||
[GetNonDefNonCopy]: ../../features/arbitrary_types.md#how-can-i-use-get-for-non-default-constructiblenon-copyable-types
|
||||
|
||||
!!! info "Types without members"
|
||||
|
||||
The member list may be empty. The macro then generates a `to_json` that produces an empty JSON object
|
||||
`#!json {}`, and a `from_json` that reads no members:
|
||||
|
||||
```cpp
|
||||
struct marker
|
||||
{
|
||||
NLOHMANN_DEFINE_TYPE_INTRUSIVE(marker)
|
||||
};
|
||||
```
|
||||
|
||||
The `WITH_NAMES` variants do not support this.
|
||||
|
||||
!!! warning "Implementation limits"
|
||||
|
||||
- The current implementation is limited to at most 63 member variables. If you want to serialize/deserialize types
|
||||
|
||||
@@ -33,7 +33,8 @@ Summary:
|
||||
: name of the type (class, struct) to serialize/deserialize
|
||||
|
||||
`member` (in)
|
||||
: name of the (public) member variable to serialize/deserialize; up to 63 members can be given as a comma-separated list
|
||||
: name of the (public) member variable to serialize/deserialize; up to 63 members can be given as a
|
||||
comma-separated list, which may also be empty
|
||||
|
||||
## Default definition
|
||||
|
||||
@@ -59,6 +60,18 @@ See the examples below for the concrete generated code.
|
||||
|
||||
[GetNonDefNonCopy]: ../../features/arbitrary_types.md#how-can-i-use-get-for-non-default-constructiblenon-copyable-types
|
||||
|
||||
!!! info "Types without members"
|
||||
|
||||
The member list may be empty. The macro then generates a `to_json` that produces an empty JSON object
|
||||
`#!json {}`, and a `from_json` that reads no members:
|
||||
|
||||
```cpp
|
||||
struct marker {};
|
||||
NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(marker)
|
||||
```
|
||||
|
||||
The `WITH_NAMES` variants do not support this.
|
||||
|
||||
!!! warning "Implementation limits"
|
||||
|
||||
- The current implementation is limited to at most 63 member variables. If you want to serialize/deserialize types
|
||||
|
||||
@@ -215,6 +215,24 @@ For _derived_ classes and structs, use the following macros
|
||||
nlohmann::ordered_json j = p; // keys appear in declaration order: name, address, age
|
||||
```
|
||||
|
||||
!!! note "Zero-member types"
|
||||
|
||||
All 12 `NLOHMANN_DEFINE_TYPE_*`/`NLOHMANN_DEFINE_DERIVED_TYPE_*` macros (excluding the `WITH_NAMES` variants)
|
||||
also accept types with no member variables to serialize, producing/accepting an empty JSON object `{}`
|
||||
(or, for the derived-type macros, just the base class's own JSON representation):
|
||||
|
||||
```cpp
|
||||
namespace ns {
|
||||
struct marker {
|
||||
bool operator==(const marker&) const { return true; }
|
||||
NLOHMANN_DEFINE_TYPE_INTRUSIVE(marker)
|
||||
};
|
||||
}
|
||||
|
||||
ns::marker m{};
|
||||
nlohmann::json j = m; // {}
|
||||
```
|
||||
|
||||
!!! note "No macro for non-default-constructible types"
|
||||
|
||||
There is currently no `NLOHMANN_DEFINE_TYPE_*`-style macro for types that are not
|
||||
|
||||
Reference in New Issue
Block a user