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

user-defined types ter: clean, refactor basic_json class #423

Closed

Conversation

theodelrieu
Copy link
Contributor

@theodelrieu theodelrieu commented Jan 9, 2017

Hi!

This PR is the follow-up of #355

I managed to replace a lot of constructors with from/to_json overloads, which helped me to remove some SFINAE boilerplate, and to add a new feature: giving full control on type serialization to whom needs it.

I advise reviewers to review commit per commit, I tried my best to separate everything.

Things that need to be done

  • Put back and adapt the docs (I got a heavy hand on the 'delete' button)
  • static assert message improvement
  • improve README (talk about specializing types supported by the library, improve clarity)
  • TODO fill this row if something comes to mind

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.3%) to 99.724% when pulling 4282130 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

{
return get_impl(static_cast<ValueType*>(nullptr));
-> decltype(this->get_impl(static_cast<ValueType *>(nullptr))) {
return get_impl(static_cast<ValueType *>(nullptr));
Copy link
Contributor

Choose a reason for hiding this comment

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

The brace here doesn't match the style of the rest of the library.

{
if (!j.is_boolean())
throw std::domain_error("type must be boolean, but is " + type_name(j));
b = *const_cast<Json&>(j).template get_ptr<typename Json::boolean_t*>();
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there no way to do this without a const_cast?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it can, adding const to the get_ptr template arg should be good

{
if (!j.is_string())
throw std::domain_error("type must be string, but is " + type_name(j));
s = *const_cast<Json&>(j).template get_ptr<typename Json::string_t*>();
Copy link
Contributor

Choose a reason for hiding this comment

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

As in boolean version, can this be done without const_cast?

friend bool operator==(json_pointer const &lhs,
json_pointer const &rhs) noexcept
{
return lhs.reference_tokens == rhs.reference_tokens;
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like this library uses 4 space indents.

Copy link
Contributor Author

@theodelrieu theodelrieu Jan 9, 2017

Choose a reason for hiding this comment

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

I added run make pretty to the list of things to be done

/// the reference tokens
std::vector<std::string> reference_tokens {};
};
};
Copy link
Contributor

Choose a reason for hiding this comment

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

Something still seems off about this brace indentation.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.3%) to 99.724% when pulling 183100f on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.2%) to 99.803% when pulling f603e76 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.2%) to 99.803% when pulling f603e76 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.2%) to 99.803% when pulling 51acff5 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@theodelrieu theodelrieu force-pushed the feature/fromtojson branch 4 times, most recently from bed76d7 to 2f85d37 Compare January 12, 2017 23:01
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.2%) to 99.803% when pulling 2f85d37 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.2%) to 99.803% when pulling 2f85d37 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.2%) to 99.803% when pulling 2f85d37 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.2%) to 99.803% when pulling 2f85d37 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@theodelrieu theodelrieu force-pushed the feature/fromtojson branch 3 times, most recently from 8cc2423 to 7a7bc07 Compare January 14, 2017 00:51
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 99.961% when pulling fc16270 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@theodelrieu
Copy link
Contributor Author

I think the unit-udt.cpp tests are quite good. And the whole library uses the to/from_json machinery now, that adds even more testing to the feature.

If someone finds an edge-case, or something I missed, please let me know

@theodelrieu
Copy link
Contributor Author

@nlohmann Hi Niels, do you think we could meet on Slack soon? I'd like to have your input on some things
(mainly documentation, the refactoring and some questions that are hidden in code comments right now)

See you soon!

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 3affbfa on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 3affbfa on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 3affbfa on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@theodelrieu
Copy link
Contributor Author

theodelrieu commented Jan 15, 2017

I added a bit of doc, but frankly I'm terrible at this, so I'd gladly take some help on this part!

But once the doc and examples are done, I think we can merge it.

EDIT:
There is one question remaining though, it's about the get method.

Right now we have this

json j;
auto v = json.get<std::vector<int>&>();
// decltype(v) == std::vector<int>
auto u = json.get<const std::vector<int>>();
//decltype(u) == decltype(v)

I uncvref the template types that are passed to the get method, which is why we have this behavior.

I think it doesn't make any sense, so I tried to remove that and add some static_asserts.

However, it broke the existing tests, in unit-pointer_access.cpp which calls get<const ptr_type>(),
it seems that there's a special behavior when get() is called with types that match those in the basic_json template argument list (boolean_t, number_integer_t, etc...)

So, should we keep this behavior for those types, and static_assert for the rest? Or do we just keep using uncvref_t?

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 85a1f29 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 1cb3b59 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 5c47ce3 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 5c47ce3 on theodelrieu:feature/fromtojson into 748250e on nlohmann:feature/fromtojson.

@theodelrieu
Copy link
Contributor Author

Unless I missed something, it is ready to be merged (minus documentation).
@nlohmann I kept all the primitive_iterator_t methods in the end, they are needed to avoid the implicit conversion madness

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 8d2216f on theodelrieu:feature/fromtojson into 145188f on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 9c6ef74 on theodelrieu:feature/fromtojson into 145188f on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 9f8b270 on theodelrieu:feature/fromtojson into 145188f on nlohmann:feature/fromtojson.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 9f103d1 on theodelrieu:feature/fromtojson into 145188f on nlohmann:feature/fromtojson.

@theodelrieu
Copy link
Contributor Author

@nlohmann Code-wise, I'm done! Ready to merge :)

@nlohmann
Copy link
Owner

Very nice! I see whether I can do the merge tomorrow.

@nlohmann
Copy link
Owner

Changes moved to #435 which will be merged once the tests complete. Thanks everybody for the hard work over the last months!

@nlohmann nlohmann closed this Jan 24, 2017
@theodelrieu theodelrieu deleted the feature/fromtojson branch January 24, 2017 14:34
nlohmann added a commit that referenced this pull request Jan 27, 2017
conversion from/to user-defined types
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants