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/
