Skip to content

Build issue with std::optional #4740

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

Closed
2 tasks
vtstmn opened this issue Apr 13, 2025 · 6 comments · Fixed by #4742
Closed
2 tasks

Build issue with std::optional #4740

vtstmn opened this issue Apr 13, 2025 · 6 comments · Fixed by #4742
Labels
kind: bug solution: proposed fix a fix for the issue has been proposed and waits for confirmation

Comments

@vtstmn
Copy link

vtstmn commented Apr 13, 2025

Description

Hi,
So great the library now support std::optional!
But I have a build issue with the following simple code.
Do you have any idea?
Thank you.
Vincent

Reproduction steps

Just compile the code

Expected vs. actual results

Compile should be successful

Minimal code example

#include <nlohmann/json.hpp>
#include <iostream>

#if 1
struct toto final
{
  std::optional<std::string> host;
  std::optional<int> port;
  NLOHMANN_DEFINE_TYPE_INTRUSIVE_WITH_DEFAULT(toto, host, port);
};
#else
struct toto final
{
  std::string host;
  int port;
  NLOHMANN_DEFINE_TYPE_INTRUSIVE_WITH_DEFAULT(toto, host, port);
};
#endif

int main()
{
  auto t0 = toto();
  auto j = nlohmann::json(t0);
  std::cout << j.dump(2) << std::endl;
  auto t1 = nlohmann::json::parse(j.dump()).get<toto>();
  return 0;
}

Error messages

'nlohmann::json_abi_v3_12_0::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::json_abi_v3_12_0::adl_serializer,std::vector<uint8_t,std::allocator<uint8_t>>,void>::get_to': no matching overloaded function found

Compiler and operating system

Visual Studio 2022

Library version

3.12.0

Validation

@vtstmn
Copy link
Author

vtstmn commented Apr 13, 2025

Adding the following code is a workaround:

namespace nlohmann
{
template
struct adl_serializer<std::optional>
{
static void to_json(json& j, std::optional const& o)
{
if (!o) { j = nullptr; } else { j = *o; }
}
static std::optional from_json(json const& j)
{
return j.is_null() ? std::make_optional() : std::make_optional(j.get());
}
};
};

@vtstmn
Copy link
Author

vtstmn commented Apr 13, 2025

Problem with #ifndef JSON_USE_IMPLICIT_CONVERSIONS in from_json.hpp I think.
The test should be #if JSON_USE_IMPLICIT_CONVERSIONS==0 or something like that,, or remove the #ifndef completely.
When not defined it's forced to 1 in macro_scope.hpp and if defined to 0 then the #ifndef blocks the insertion of code.

@nlohmann
Copy link
Owner

Good catch!

However, after replacing the #ifdef with an #if and adding a test like this:

const auto t0 = Example_4740();
const auto j = nlohmann::json(t0);
CHECK(j.dump() == "{\"host\":null,\"port\":null}");

all is fine, but adding

auto t1 = j.get<Example_4740>();
CHECK(!t1.host.has_value());
CHECK(!t1.port.has_value());

again breaks the build.

Now, I am unsure why we have the check for JSON_USE_IMPLICIT_CONVERSIONS in the first place.

I created a PR #4742 to test this. Please take a look.

@nlohmann nlohmann added state: please discuss please discuss the issue or vote for your favorite option solution: proposed fix a fix for the issue has been proposed and waits for confirmation labels Apr 14, 2025
@nlohmann nlohmann linked a pull request Apr 14, 2025 that will close this issue
@vtstmn
Copy link
Author

vtstmn commented Apr 14, 2025

I think the JSON_USE_IMPLICIT_CONVERSIONS check should be removed. The test code should compile and work with JSON_USE_IMPLICIT_CONVERSIONS set to 0 or set to 1.

@nlohmann
Copy link
Owner

Thanks, it does - the MR has a green CI and I only need to add another test to improve the code coverage.

@nlohmann nlohmann added this to the Release 3.12.1 milestone Apr 14, 2025
@nlohmann
Copy link
Owner

@vtstmn Please take a look at #4742.

@nlohmann nlohmann removed the state: please discuss please discuss the issue or vote for your favorite option label Apr 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: bug solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants