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.
You're not looking at this from the perspective of a library developer who wants to check header files as they're being developed.
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!
-- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
