I've run into this warning with C++ code as well, and it is quite annoying. There are lots of possible reasons to want to do this sort of thing, and adding a virtual dtor increases the size of the vtable for the class.
Yeah, there goes one whole pointer per class in your program image. :-) Seriously, you'd have to have a lot of classes and not very many objects before that got to be *too* big a deal. But, we do have customers who count every byte, so I'm not totally discounting this objection.
For me, it's much more of an irritation factor than anything else. I agree that saving a couple pointers per class isn't a big deal.
It seems that the warning could be improved to be emitted when the *delete* is seen of a class without a virtual dtor (but that does have virtual methods). If you never actually do the questionable behavior, you'd never get the warning. It seems like a bug to emit it for the class definition.
Age-old debate: better to warn early about possibly broken interfaces, or late about definitely broken usage? I think that warning early, together with what DJ is calling fine-grained warning control is the best solution.
I don't agree at all on this. It's not a matter of warning vs not warning: it's a matter of emitting bogus warnings *sometimes* when you can emit the proper warning *all of the time*. Given a choice of an accurate warning vs an warning that fires on a superset of the cases, I'd prefer the former. Warning "late" may just be a synonym for warning only where there is a problem, as opposed to in every translation unit that includes the header. :)
-Chris
-- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
