-
Notifications
You must be signed in to change notification settings - Fork 133
[vs2017] warning C4265: class has virtual functions, but destructor is not virtual #195
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
Conversation
Hi, could you please squash it to one commit? Other than that it looks good to me :) |
This thing is not a problem because we never delete through a pointer to the base class. So this warning is in effect a false positive. We already have a few Visual Studio-only warning workarounds in that add code with no other value than that. Is there another way to make it stop giving this warning? If not, then I want to see a comment near every virtual destructor that you add that the sole reason is this particular warning (C4265) of visual studio. |
a7130e1
to
5cee6be
Compare
@muggenhor, I found this discussion: [StackOverflow]Should every class have a virtual destructor? #ifdef _MSC_VER
#pragma warning(push)
#pragma warning(disable: 4265)
#endif
// ...
#ifdef _MSC_VER
#pragma warning(pop)
#endif Both points of view are defendable. Please tell me what you decide and I will change the pull request accordingly? |
Given that these classes already have virtual functions they already have a vtable. So while the size of that will increase, the size of the pointer to the vtable won't increase (that's the only per-object item). So that's not the issue here. The problem is that you're violating the rule of 0 (specify no special member functions), without following the rule of 3/rule of 5 (specify all special member functions). That's the real cost of specifying a virtual destructor without needing it: you incur a larger maintenance cost. That's not a problem if there's a need for it, there isn't.
I agree that the pragmas for disabling these warnings are not desired. Instead I prefer to have these disabled with |
Actually I got these errors in client 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.
Right, well that's disappointing.
5cee6be
to
004df16
Compare
004df16
to
0032338
Compare
@muggenhor, please could you review the last version ? |
Hello @muggenhor, |
this thing IS a problem:
detail:
|
The fact that this issue comes up not only with test harness but also with examples makes me think that derivatives of @muggenhor @matlo607 I don't have write access but I've checked this locally with clang and it seem to work just as fine so I just went ahead and started a new pull request #209 |
Not true:
|
@matlo607 Thanks for your contribution and apologies for looking at this quite late. To be honest, I would remove the comments. This PR in the repo history should be enough documentation and I'd rather not have clutter. May I ask you to remove them? I'll merge it right away afterwards. |
@paoloambrosio I removed the comments. |
No idea what is happening with the Appveyor build 🤦♂️ |
See discussion in this same PR
Switching over to ruby 2.2.x on appveyor fixes problem seen here, so at least it builds and unit tests are running ok, but then e2e tests are failing, see: It's our own dependency hell as bug in cucumber > 2.0 won't work with cucumber-cpp :/ |
Created #217 to fix the build. |
Verified this builds when rebased against current master. Merging it even if the build didn't pass at the time. |
…destructor is not virtual'
VS2017 triggers the following warnings: