On Fri, 4 Mar 2005, Mark Mitchell wrote:
Chris Lattner wrote:
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.
The point is that it's a common error to forget the virtual destructor. If you're writing a library, and you put such a class in a header, you often want a warning *right then* -- not when a customer somewhere tries to use your library and uses delete on some class in your library.
Sure, that makes sense. I agree that it's good to know early. :)
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.
Yes -- what if a user of your library will need it to be virtual?
In my mind, the times you want to silence the warning (without defining the virtual dtor) are when you *know* that it will never be used that way, because it's part of the contract of the class.
I could agree that there should be no warning if the class declares a private operator delete. But, that kind of thing is a refinement.
I think this would be a great refinement (if you extended it to protected dtors also). Given this, a library author would initially get the warning, then have two options for silencing it: a) define the virtual dtor if it makes sense, or b) mark the dtor protected/private to explicitly state the intention.
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
That's not fine-grained. Fine-grained is a pragma/attribute you can put on the class to say "don't issue this warning about this class."
Okay, sure, if there is a per-class way of disabling the warning (either something explicitly at the source level, like the above, or a #pragma gcc or something), that would be fine. I didn't know anyone was even considering doing this with GCC.
-Chris
-- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
