-
Notifications
You must be signed in to change notification settings - Fork 910
Lint pass: ctor initializer order + virtual dtors #865
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
This commit enables new warnings for the MSVC compiler: - C4265: Class has virtual functions, but its non-trivial destructor is not virtual. - C5204: Class has virtual functions, but its trivial destructor is not virtual. - C5038: Data member will be initialized after [other] data member The first two warnings catch cases where destructors don't cascade when someone forgets to specify that a derived class's destructor is virtual. The third warning flags the situation where a class's data members are specified in one order, and the initializers are listed in a different order. Member variables are always initialized in class declaration order, so programmers who expect initialization in initializer list order may be surprised, particularly when some members depend on other members being initialized first. I've cleaned the code and books from the above warnings.
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.
Should I add warnings to the CMAKE for clang compilation?
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.
Seems mostly positive.
All of these book changes will need diligent checking after the fact.
But, at least for today, virtual destructors was probably overdue
Yes, add |
Oops, forgot to @trevordblack . |
Couple of questions:
|
Getting up and going for both clang and gcc is trivial:
But clang and gcc have different warnings (this also varies across versions, yay!) I think there's value in having the superset of all MSVC, clang, and gcc warnings spit out to you and me, but I think it would be really annoying/confusing/discouraging for new comers. I'm saying we should make a build farm. |
With
|
With
|
I also tried |
That stb warning seems to have been slightly rewritten in a later release:
Making that change locally removes the warning |
Having gcc and clang spit out the same warnings as msvc requires:
|
Ugh. Some thoughts: I have to deal with the vagaries of clang and gcc on Mac at work as well. Every version's different, including Still, this is useful. As a one-off manual exercise, sure, but it would be nice to also have a consistent build set for validation of externally submitted PRs. And yet, I don't want to have to spool up builds on my Mac and run on the X different platforms for every change. I'm thinking that we should just do this ad hoc as we've been doing. If tools reveal a flaw, we'll just fix the flaw. I agree with you that we should keep the build tools dead simple for readers. I also don't care at all about warnings coming out of We do have a bunch of unused parameters, but that's unhelpfully fussy in my opinion. This is a good example of why some warnings should be optional. We could go with the pattern of Unused/uninitialized variables we should definitely fix. |
Oh, another thing. I do think the MSVC compiler flags are nice in the |
I 100% agree with everything you've said. |
Ok, so keep the current MSVC flags and add some general |
okee doke. |
Thanks! Fun fact -- I can't approve, because I authored some of the commits, and presumably neither can you, for the same reason. Oh well. |
This commit enables new warnings for the MSVC compiler:
not virtual.
virtual.
The first two warnings catch cases where destructors don't cascade when
someone forgets to specify that a derived class's destructor is virtual.
The third warning flags the situation where a class's data members are
specified in one order, and the initializers are listed in a different
order. Member variables are always initialized in class declaration
order, so programmers who expect initialization in initializer list
order may be surprised, particularly when some members depend on other
members being initialized first.
I've cleaned the code and books from the above warnings.