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

Added support for string_view in C++17 #1028

Merged
merged 11 commits into from
Jun 23, 2018
Merged

Conversation

gracicot
Copy link
Contributor

This patch adds support for std::string_view conversion (explicit and implicit). It also added construction from std::string_view.

I did that by following how many compatible array types were handled and adding a type trait that checks for compatible string types.

However, I fear the trait is kinda loose in which type is allows (see is_compatible_string_type). Tell me if it needs to be fixed!

@nlohmann
Copy link
Owner

Hey @gracicot, thanks for the PR!

{
if (JSON_UNLIKELY(not j.is_string()))
{
JSON_THROW(type_error::create(302, "type must be string, but is " + std::string(j.type_name())));
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a test case checking for this exception? If not, please add one.

@nlohmann
Copy link
Owner

There is an issue with MSVC 2017 using /std:c++latest: https://ci.appveyor.com/project/nlohmann/json/build/2697/job/f7no7s3vjq8xddu9

@coveralls
Copy link

coveralls commented Mar 29, 2018

Coverage Status

Coverage remained the same at 100.0% when pulling 14e6278 on gracicot:develop into d2dd27d on nlohmann:develop.

@gracicot
Copy link
Contributor Author

gracicot commented Apr 9, 2018

Sorry for the delay. I haven't investigated the issue with visual studio yet, I will be soon.

@nlohmann
Copy link
Owner

Any ideas on how to fix this?

@gracicot
Copy link
Contributor Author

gracicot commented May 1, 2018

I investigated and it lead me to think it's linked to #464 .

This is a MSVC bug, and If I look at cppreference, an overload of operator= taking T is defined for T only if T is convertible to a std::string_view. While digging deeper, I see that it's LWG 2946 that Microsoft hasn't yet implemented. I reported a bug about it.

I haven't found a solution yet that would allow implicit conversions to std::string_view. Maybe disallow the implicit conversion until the fix for the issue is fixed? That would at least allow get<std::string_view>

@nlohmann
Copy link
Owner

nlohmann commented May 1, 2018

I think disabling it for MSVC for the time being could be a way to go.

@stale
Copy link

stale bot commented May 31, 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 31, 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 1, 2018
@gracicot
Copy link
Contributor Author

gracicot commented Jun 1, 2018

So the bug preventing enabling this feature on msvc has been fixed: https://developercommunity.visualstudio.com/content/problem/243183/stdstring-should-not-have-a-operator-that-takes-a.html

It should be out in 15.8 (msvc 19.15?), so in 19.14 and older it is disabled, as discussed.


template<typename BasicJsonType, typename CompatibleStringType,
enable_if_t<not std::is_same<CompatibleStringType, typename BasicJsonType::string_t>::value,
int> = 0>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This SFINAE check is already done in the to_json method, maybe we can only do it once:

  • Adding a to_json(const BasicJson::string_t&) overload (only BasicJson::string_t&& is handled right now)
  • Then, in the to_json overload where the std::is_constructible<...> check is performed, construct a string_t and move it to the external_constructor.

Additionally, I'd rather keep external_constructor function count low (Maybe the array_t specialization could get cleaned a bit).

This is mostly a style preference though.

not std::is_same<typename BasicJsonType::string_t,
CompatibleStringType>::value and
std::is_constructible <
BasicJsonType, typename CompatibleStringType::value_type >::value,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this check relevant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, it's not necessary. I also missed a check elsewhere, let me fix that.

@nlohmann
Copy link
Owner

nlohmann commented Jun 7, 2018

I'm on holidays, but I will have a look at this PR once I am back at the end of June.

@nlohmann

This comment has been minimized.

Copy link
Owner

@nlohmann nlohmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

@nlohmann nlohmann self-assigned this Jun 23, 2018
@nlohmann nlohmann added this to the Release 3.1.3 milestone Jun 23, 2018
@nlohmann nlohmann merged commit bf348ca into nlohmann:develop Jun 23, 2018
@nlohmann
Copy link
Owner

Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants