Question w.r.t. `'class Foo' has virtual functions but non-virtualdestructor` warning.

[Chris Lattner]

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/