[cfe-dev] -Wweak-vtables questions

[David Blaikie]

On Thu, Aug 30, 2012 at 8:50 AM, Somorjai, Akos
<ASomorjai at graphisoft.com> wrote:
> Hi all,
>
> I'm currently experimenting with clang 3.1 (from Xcode 4.4 package on OS X
> 10.7), and I turned on the warning mentioned above. Most of the time it
> gives the correct warning, but in some situations I'd need some
> clarification:
>
> classes defined in .cpp files — is the compiler warns me because
> theoretically I can add this .cpp file into two separate modules/frameworks?

If the class is defined in an anonymous namespace then I believe we
can probably avoid emitting this as weak. (and/or just avoid the
warning at least - what it's meant to warn about (unnecessary overhead
of emitting the same vtable into multiple TUs & the link-time overhead
of having to deduplicate them all) isn't relevant when it's guaranteed
to be only in one TU)

> pure virtual interface classes — is the warning necessary here?

Technically, yes (ish) - even pure virtual interface classes have to
have vtables (ABI requirement - there's well defined (failure)
behavior if you  call a pure virtual function). It might be debatable
as to what solution users should employ in this situation & whether or
not it's worthwhile/actionable to provide this warning - for those
willing to use this warning at all, I guess it might be worthwhile.

> classes which are not exported from a module, so marked with
> __attribute__((hidden))?

I'm not especially familiar with the visibility attributes, sorry. But
if I understand you correctly when you say 'module' you mean exporting
from, say, a shared library or executable? Yes, the warning is still
relevant there - the 'weakness' of the vtable symbol is only an issue
for compile/link time performance, it should have no effect on runtime
as far as I understand it.

> Also, classes whose parent class is exported from a
> module, but the derived class is not? — is the warning necessary here?

I don't believe derived classes enter into the rationale for this warning.

(that being said - this warning exists for a fairly specific use case
& may not be something you need. (even LLVM has a style requirement
for this but isn't anywhere near clean enough to turn the warning on
in its builds))

- David