-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add migration guide #3702
Add migration guide #3702
Conversation
[`operator!=`](../api/json_pointer/operator_ne.md) is deprecated since 3.11.2. To compare a | ||
[`json_pointer`](../api/json_pointer/index.md) `p` with a string `s`, convert `s` to a `json_pointer` first and use | ||
[`json_pointer::operator==`](../api/json_pointer/operator_eq.md) or | ||
[`json_pointer::operator!=`](../api/json_pointer/operator_ne.md). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may be confusing.
The member operator==
does not replace the non-member operators due to deprecation but due to the used C++ standard version.
Until C++20 the non-member operators operator==(json_pointer, string_t)
and operator==(string_t, json_pointer)
are deprecated for operator==(json_pointer, json_pointer)
. (Same applies to operator!=
.)
Since C++20 the member operator json_pointer::operator==(string_t)
is deprecated for json_pointer::operator==(json_pointer)
. json_pointer::operator!=
does not exist in the source code but is synthesized by the compiler by rewriting the expression using json_pointer::operator==
, i.e., a == b
is rewritten as !(a == b)
.
This is by no means necessary but could reduce code size minimally. (Someone – me? – should verify that on Compiler Explorer.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also confused. Can you propose a better wording for the paragraph?
## Do not hard-code the complete library namespace | ||
|
||
The [`nlohmann` namespace](../features/namespace.md) contains two sub-namespaces to avoid problems when different | ||
versions or configurations of the library are used in the same project. Always use `nlohmann` as namespace or, when the | ||
exact version and configuration is relevant, use macro | ||
[`NLOHMANN_JSON_NAMESPACE`](../api/macros/nlohmann_json_namespace.md) to denote the namespace. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section is tricky. I keep oscillating on what is necessary and when.
I'll expand on this later.
(Also, "two sub-namespaces" is definitely wrong now.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed the "two sub-namespaces". No idea about the rest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hesitate because of the advice given here:
https://json.nlohmann.me/features/arbitrary_types/#how-do-i-convert-third-party-types
Currently, I think this section is OK (i.e., the issue is resolved for the purpose of this PR) but I'm conflicted about the advice to use NLOHMAN_JSON_NAMESPACE_BEGIN
when specializing adl_serializer
.
Co-authored-by: Florian Albrechtskirchinger <falbrechtskirchinger@gmail.com>
What do you think of a preprocessor symbol like |
That sounds like a good idea. Maybe a JSON_REMOVE_DEPRECATED_FUNCTIONS for the functions, and then a single define that sets all of the macros that remove deprecated behaviors, such as implicit conversions and the compare behavior. |
I will not do this in this PR. |
Co-authored-by: Niels Lohmann <niels.lohmann@gmail.com> Co-authored-by: Florian Albrechtskirchinger <falbrechtskirchinger@gmail.com> Co-authored-by: barcode <barcode@example.com>
* 💚 add clang-tools to required tools for ci_static_analysis_clang * 🚨 update Clang-Tidy warning selection * 🚨 fix Clang-Tidy warnings * 🚨 fix Clang-Tidy warnings * 🚨 fix Clang-Tidy warnings * 🚨 fix Clang-Tidy warnings * 🚨 fix Clang-Tidy warnings * 🚨 fix Clang-Tidy warnings * 🚨 fix Clang-Tidy warnings * 🚨 fix Clang-Tidy warnings * 🚨 fix Clang-Tidy warnings * 🚨 fix Clang-Tidy warnings * 🚨 fix Clang-Tidy warnings (#3738) * ⏪ revert fix * ⏪ revert fix * 🚨 fix Clang-Tidy warnings (#3739) Co-authored-by: Florian Albrechtskirchinger <falbrechtskirchinger@gmail.com>
…guide # Conflicts: # docs/mkdocs/docs/integration/migration_guide.md
* 🐛 fix natvis XML * 🐛 fix natvis XML
Co-authored-by: Florian Albrechtskirchinger <falbrechtskirchinger@gmail.com>
Co-authored-by: Florian Albrechtskirchinger <falbrechtskirchinger@gmail.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The migration guide collects all steps required to make the code future-proof for upcoming releases.