Skip to content
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

document that implicit js -> primitive conversion does not work for std::string::value_type and why #1052

Closed
weber-martin opened this issue Apr 12, 2018 · 6 comments

Comments

@weber-martin
Copy link

I expect to be able to convert from and to any C++ primitive type.

I can convert from and to json from basically any type but a plain "char". If trying to do so, I'm getting a compile error:

 error: cannot convert ‘nlohmann::json {aka nlohmann::basic_json<>}’ to ‘char’ in initialization
  C c2 = js;

Conversion from and to similarly sized signed char and unsigned char do work as expected, as do conversions from and to int8_t and uint8_t.

See the following file:

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

using nlohmann::json;

template <typename C>
void char_test() {
	C c1 = '?';
	json js = c1;
	C c2 = js;

	std::cout << " c1: " << c1 << " js: " << js << " c2: " << c2 << std::endl;
}

int main(int, char **) {
	char_test<int8_t>();
	char_test<uint8_t>();
	char_test<signed char>();
	char_test<unsigned char>();
	//char_test<char>();
	return 0;
}

uncomment the second to last line in main() to get the compile error.

Compiled with g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 on Linux 4.12.0-0.bpo.2-amd64 x86_64 invoked as g++ -Wextra -Wall -Werror -std=c++11 -I $NLOHMANN_JSON_SINGLE_INCLUDE_DIR -o minimal minimal.cpp

This is with nlohmann-json commit 46ec2fddf8774af2f9368bf563dd6e32fa91d77e

Nope, I don't have a cmake 3.8 handy.

@nlohmann
Copy link
Owner

This seems to be a duplicate of #276.

@weber-martin
Copy link
Author

Oh ok. Apologies; I looked at the open issues and went to see if I could reproduce it with HEAD, I did not look at the closed "wontfix" issues

Is this documented? It didn't stand out to me when I went over the existing documentation.
If it isn't, then consider this issue a documentation request. ;)

@weber-martin weber-martin changed the title js to char document that implicit js -> primitive conversion does not work for std::string::value_type and why Apr 16, 2018
@weber-martin
Copy link
Author

weber-martin commented Apr 16, 2018

A good solution indeed is using #get().
One thing to remember though, in contrast to using the implicit type conversion, is that this might require an extra "template" when calling the ".get" (i.e. yadda yadda.template get<..>()) if you are using the json interface in templated code (sure, that's "basic C++ template knowledge" I suppose, but after years this interface is the first one where I had to use it, so I believe the extra reminder does not hurt)

@stale
Copy link

stale bot commented May 17, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label May 17, 2018
@tamaroth
Copy link

I'd like to add a comment.

When using GCC 7.2.0 the following code works perfectly:

JSON j = "{ \"happy\": \"maybe\", \"pi\": 3.141 }"_json;
std::string hp(j["happy"]);

When compiling the same code with GCC 8.0.1, it does not compile with the following error:

error: call of overloaded ‘basic_string(nlohmann::basic_json<>::value_type&)’ is ambiguous

Of course using explicit conversion works flawlessly:

JSON j = "{ \"happy\": \"maybe\", \"pi\": 3.141 }"_json;
std::string hp(j["happy"].get<std::string>());

I thought I mention since 8.0.1 is out.

@stale stale bot removed the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label May 23, 2018
@stale
Copy link

stale bot commented Jun 22, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Jun 22, 2018
@nlohmann nlohmann added this to the Release 3.1.3 milestone Jun 22, 2018
@stale stale bot removed the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Jun 22, 2018
nlohmann added a commit that referenced this issue Jun 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants