Re: Question w.r.t. `'class Foo' has virtual functions butnon-virtualdestructor` warning.

[Chris Lattner <sabre at nondot dot org>]

On Fri, 4 Mar 2005, Mark Mitchell wrote:
> Chris Lattner wrote:
> > > 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. 
> > :)
>
> I understand where you're coming from.  The reason I said age-old debate is 
> that we spent *weeks* worrying about this stuff for our error-checking tools 
> at CenterLine, and talking to customers, and so forth and so on, and there 
> was lots of passion on both sides.  There really isn't a right answer.

Sure, I agree and I definitely see where you are coming from.

> You're not looking at this from the perspective of a library developer who 
> wants to check header files as they're being developed.

I'm not sure I understand your point here.  The library developer writes a 
class, and does not *want* it to be destroyed through the base class.  As 
a library designer, I can intentionally make the dtor protected, making it 
pretty clear that delete should not be called on the base class.

With the current implementation of the warning, as a library designer, I 
am force to make the dtor virtual, even if there is no need in my library 
for it to be so.  This means that the dtors of derived classes will 
implicitly be virtual, even if they don't need it.  This (admitedly not 
likely to be a problem in practice) introduced extra virtual function 
calls because C++ doesn't have something like Java's "final" attribute 
for classes.

Furthermore, even fine-grained warning control (at least on a per t-u 
basis) doesn't help me with this.  As a library developer, forcing all of 
my clients to disable the (very useful) warning may potentially hide 
problems in *their* code.

> People actually make the same argument sometimes about things like:
>
> void f() {
>  int *p = 0;
>  *p = 3;
> }
> saying "but I never call f, so I don't want a warning for it".

> Languages like Python or LISP are the (extreme) logical extension of your 
> point of view: just start running the program and if anything goes wrong, 
> tell me about when it happens!

Sure fine, but this particular warning is not nearly as extreme as either 
of those.  Note that in the case of "f" there is no way to call the 
function, so that is worth a warning.  In the case we're discussing, there 
are *perfectly valid* ways to use the class, which are not even really 
that obscure.

In the end, I have to support older versions of GCC with my code, so this 
discussion is somewhat academic to me.  However, personally, I think that 
refining this warning would be a simple quality of implementation 
improvement.  *shrug*

-Chris

--
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/