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

Fixing assignement for iterator wrapper second, and adding unit test #579

Merged
merged 3 commits into from
May 13, 2017

Conversation

Type1J
Copy link
Contributor

@Type1J Type1J commented May 10, 2017

To complete #350 and #578, this PR adds an assignment operator and a new unit test for the iterator wrapper functionality with .first and .second.

@Type1J
Copy link
Contributor Author

Type1J commented May 10, 2017

Running the test cases, I get:

$ json_unit iterator_wrapper
===============================================================================
All tests passed (111 assertions in 1 test case)


$ json_unit iterator_wrapper_first_second
===============================================================================
All tests passed (111 assertions in 1 test case)

The new iterator_wrapper_first_second test is a duplicate of the regular iterator_wrapper test with all .key() calls replaced with .first and all .value() calls replaced with .second

@coveralls
Copy link

Coverage Status

Coverage remained the same at 99.722% when pulling d6c78da on Type1J:develop_feature_first_second into 5beea35 on nlohmann:develop.

@nlohmann
Copy link
Owner

As Travis is sometimes buggy, I restarted the failing tests (see https://travis-ci.org/nlohmann/json/builds/230863073), but I fear that there is a problem with Clang, but also newer GCC versions.

@nlohmann
Copy link
Owner

Travis came to the same results: all compilers but GCC 4.9 fail, see see https://travis-ci.org/nlohmann/json/builds/230863073.

@Type1J
Copy link
Contributor Author

Type1J commented May 11, 2017

I see. I'll look into it. This it probably a good case for operator.(), but it's not supported by most compilers. To make it work for everything, I think I'll need to add operator==(), operator!=() for both types.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 99.722% when pulling 00d841b on Type1J:develop_feature_first_second into 5beea35 on nlohmann:develop.

@gregmarr
Copy link
Contributor

operator.() is not standard. It has been proposed but hasn't yet been approved.

@Type1J
Copy link
Contributor Author

Type1J commented May 11, 2017

I'm getting Clang to see if I can fix this issue. I may have to generate a reverse patch to remove the code (apparently, it's not supported by all compilers).

@Type1J
Copy link
Contributor Author

Type1J commented May 11, 2017

Clang seems to be happy after making the compares const.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 99.722% when pulling b78457b on Type1J:develop_feature_first_second into 5beea35 on nlohmann:develop.

@nlohmann
Copy link
Owner

The unit tests succeed now. Great! I'll merge this tonight.

@nlohmann nlohmann merged commit 8b88e1b into nlohmann:develop May 13, 2017
@nlohmann nlohmann self-assigned this May 13, 2017
@nlohmann nlohmann added this to the Release 3.0.0 milestone May 13, 2017
@Type1J Type1J deleted the develop_feature_first_second branch May 13, 2017 14:11
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