类似 COM 的接口对非虚拟析构函数发出警告
有没有办法告诉 gcc 它正在编译的抽象类不需要虚拟析构函数（就像 COM 对象从来没有）？ 例如 nsISupports 总是抱怨缺少虚拟析构函数。 关闭警告不会有帮助，因为我可能有非类似 COM 的类，我希望在其中出现此警告。
因此 __attribute__((com_interface)) 已被弃用，仅更改了 vtable 布局。 是否还有另一个 __attribute__ 可以告诉编译器我不想收到关于此类缺少析构函数的警告？
Is there a way to tell gcc that the abstract class it's compiling does not need a virtual destructor (like COM-objects never have)? For example nsISupports always complains about the missing virtual destructor. Turning off the warning would not help as I may have non-COM-like classes, where I want this warning.
So __attribute__((com_interface)) is deprecated and changed only the vtable layout. Is there another __attribute__ where I can tell the compiler that I don't want to be warned about the missing destructor on this class?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
缺少虚拟 dtor 警告的存在是有原因的 - 主要是因为它是一个调试噩梦，尤其是在大型且复杂的代码库中
您可能有一个非常具体的原因这样做，但问问自己，如果一个类被重构，以致它的用法稍后发生变化，会发生什么？
The missing virtual dtor warning is there for a reason - mainly because it's a debugging nightmare to track down, especially in a large and complex code base
You may have a very specific reason for doing this but ask yourself, what happens if a class gets refactored such that it's usage changes later down the line?
我认为您应该重新考虑禁用此警告。 它的存在是有原因的。 今天，不在您的类中放置虚拟析构函数可能是正确的，但您无法准确预测您的类将来将如何使用。
类使用方式的细微变化可能会导致下一个开发人员费尽心思花费数小时来试图追踪资源泄漏。 帮那个人一个忙，现在让析构函数虚拟化。
您也可能想问自己
你提到有一个抽象类，所以我假设它至少有一个虚拟函数。 因此，使析构函数成为虚拟的不会向对象添加 v 表，它只是将其扩展以包含另一个成员。
我看不到使这个非虚拟化有任何真正的好处。 只有问题。
I think you should re-consider disabling this warning. It's there for a reason. Not putting a virtual destructor in your class may be correct today, but you cannot predict exactly how your class will be used in the future.
A subtle change in the way the class is used could lead to the next developer pulling their hair out for hours trying to track down a resource leak. Do that person a favor and make the destructor virtual now.
Also you may want to ask yourself
You mentioned having an abstract class so I assume it has at least a single virtual function. So making the destructor virtual doesn't add a v-table to the object, it just merely extends it to include another member.
I can't see any real gain in making this non-virtual. Only problems.
您可能想使用一对 诊断语用。 如果失败，
#pragma GCC system_header将禁用给定文件中的所有警告。You probably want to use a pair of diagnostic pragmas. Failing that,
#pragma GCC system_headerdisables all warnings in a given file.