Community
Participate
Working Groups
Build Identifier: M20100909-0800 For example, class A { public: virtual f() = 0; }; This class has the default non-virtual destructor which is generated by compiler. In this case Codan doesn't provide a warning about absence of a virtual destructor for a class with virtual methods. Reproducible: Always
I believe this works now
Or maybe not? Somehow the fact that the method is abstract affects the checker's result. If one would derive from this class, the derived class would have the warning. I have no idea whether this is a design decision or a class Abstract { // no warning - but it should be virtual void foo() = 0; }; class Base : Abstract { // a warning - correct, but possibly undesired, see discussion on bug 315528 }; Anyway- this is related to bug 315528 which discusses the behaviour of this checker. There seems to be a discussion under way and there are several more issues to address.
(In reply to comment #2) > Or maybe not? Somehow the fact that the method is abstract affects the > checker's result. If one would derive from this class, the derived class would > have the warning. I have no idea whether this is a design decision or a This is intentional. An abstract class cannot be instantiated. Therefore there is no need to worry about the dtor. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=315528#c30 and http://www.parashift.com/c++-faq-lite/abcs.html A base class with only pure virtual methods defined results in the same interface concept as the keyword "interface" does in Java.
This is true, but I'd still write an empty virtual destructor in such "interface" class, so that I won't have to re-define it in every concrete class implementing this interface. This is probably just a matter of taste or programming style. I can agree that the warning here is not obligatory. Anyway- in this case, an "empty" class deriving from such an interface class would be abstract too, so it consequently shouldn't also have any warnings. I suggest we mark this a duplicate of 315528 (since it's the very same matter) and continue the discussion there. I'll provide more test cases in a minute.
The example in comment 0 currently gives a warning as requested (tested with Kepler). As for whether it should or not, it looks like it has been discussed extensively in bug 315528, which has been closed as fixed. I think this bug can be closed as fixed now.
Closing per comment 5.
