虚拟方法，但没有虚拟破坏者
我在GNU编译器上看到了这样的警告
destructor called on non-final 'some_class_type' that has virtual functions but non-virtual destructor
，但是在我们的内部连续集成测试中也使用clang编译，此警告成为一个错误。
这是应该发生的吗？如果是这样，为什么Clang将其描述为错误，而GNU则没有？
I see warnings like this
destructor called on non-final 'some_class_type' that has virtual functions but non-virtual destructor
on gnu compilers, but on our internal continuous integration tests that also compiles with clang, this warning becomes an error.
Is this supposed to happen, and if so, why does clang characterize this as an error, but gnu doesn't?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
按照标准进行：如果该程序成型良好，则该程序应该可以成功编译。允许编译器提供诊断消息。缺乏虚拟驱动器并不能使该程序形成不佳，即使在这种情况下可能是一个错误。
编译器通常可以选择将警告视为错误。给定这样的选择，即使在技术上不符合标准，也应该发生描述的行为。
叮当声以将警告视为错误。给定这样的选项已启用，可以解释这种行为。
尽管GCC也可以配置为将警告视为错误，但如果未启用此类选项，则可以解释这种行为。
为了解决问题，请将灾难将其声明为虚拟。
According to standard: If the program is well-formed, then the program is supposed to be compiled successfully. The compiler is allowed to provide diagnostic messages. Lack of virtual destructor does not make the program ill-formed, even though it's a likely bug in this case.
Compilers typically have the option to treat warnings as errors. Given such option, the described behaviour is supposed to happen, even though that technically doesn't conform to the standard.
Clang can be configured to treat warnings as errors. Given such option is enabled, that would explain this behaviour.
Although GCC can also be configured to treat warnings as errors, if such option isn't enabled, that would explain this behaviour.
To solve the problem, declare the destructor as virtual.