views:

184

answers:

3

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?

A: 

You probably want to use a pair of diagnostic pragmas. Failing that, #pragma GCC system_header disables all warnings in a given file.

David Seiler
+1  A: 

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?

zebrabox
+1  A: 

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

What do I gain by making it non-virtual

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.

JaredPar
Thanks. But with COM-like I meant xpcom, windows com or something similar. IUnknown of windows has no virtual destructor. nsISupports of mozilla has no virtual destructor. These classes and their derivates are always deleted with a IUnknown/nsISupports::release() function. Deleting them with delete is not wanted. So is there a reason why COM-interfaces do not have a virtual destructor but other classes have it?
gri