-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
Fix -Weffc++ warnings (GNU 6.3.1) #496
Fix -Weffc++ warnings (GNU 6.3.1) #496
Conversation
src/json.hpp.re2c
Outdated
@@ -6168,6 +6168,21 @@ class basic_json | |||
thousands_sep(!loc->thousands_sep ? '\0' : loc->thousands_sep[0]), | |||
decimal_point(!loc->decimal_point ? '\0' : loc->decimal_point[0]) | |||
{} | |||
serializer(const serializer& cpy) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't actually need to copy a serializer, so this should rather be
serializer(const serializer&) = delete;
serializer& operator=(const serializer&) = delete;
to make GCC happy without adding unneeded features.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree, we should = default
everything, since this is the actual behaviour.
Deleting them would potentially break code for no good reason.
I've read some comments about -Weff-c++ not being very relevant, (and I believe this warning is a bit too much).
But since this PR is really short, I think we can still merge it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The serializer class is private and only used inside the dump
function, so no code should rely on it. Doing nothing and relying on default behavior is fine (I could live with the -Weffc++
warnings), but making explicit that we do not intent to copy serializers feels cleaner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that there is no need to copy it in the first place, since this is like a traits struct, with no attributes.
I didn't look at the diff, but if we need to add explicit constructors on stuff like detail::is_nested_class
, just to support this warning, I really think this isn't worth it, the tests do not build with it, and I believe people who want to use it in their codebase should include json.hpp
with -isystem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added my proposed two lines to json.hpp
and the -Weffc++
warnings disappeared. I think there is no need to change other code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, but I still think we should = default
all operations if we're going down that road.
It's an empty struct after all. Also, nobody ever declares a variable of type std::is_same<int, void> pointless;
.
However pointless
is still copyable, moveable etc.
This might be nit-picking, but I don't see a good reason to delete those constructors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not talking about changing anything but the serializer class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wait a Minute, iI thought it was the adl_serializer!
Sorry I'm on my phone , didn't get that!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi! I made the proposed change (and made the new serializer methods private too).
Do I need to create a new pull request for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, you can change this PR. Could you check why AppVeyor failed?
@TedLyngmo, thanks! I shall merge when Travis finished! |
Ran “make pretty” and added a note to the README file.
Adding constructors and assignment operators where needed to keep -Weffc++ happy.
src/json.hpp regenerated with re2c 0.16 and manually edited to keep the indentation ok.