-Wweak-vtables questions

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:

  1. classes defined in .cpp files — is the compiler warns me because theoretically I can add this .cpp file into two separate modules/frameworks?
  2. pure virtual interface classes — is the warning necessary here?
  3. classes which are not exported from a module, so marked with attribute((hidden))? Also, classes whose parent class is exported from a module, but the derived class is not? — is the warning necessary here?
    Thanks, Akos

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

Hi David,

Thanks for the answers! The whole reason I’m trying to use this warning is to detect possible RTTI problems with shared libraries (see http://gcc.gnu.org/faq.html#dso).

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)

So, your suggestion is to have an anonymous namespace around these classes? I’ll give it a try.

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.

OK. So in this case I’ll have to fall back to add a default implementation in a source file, and add that source file to the module/shared library. Which kind of kills the whole pure virtual interface stuff…

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.

We use several modules (shared libraries, frameworks).
The hidden attributes marks a class invisible for the executable or other modules, and the compiler knows about this, as it is a language feature. So it can also be a compile time issue.

Hi David,

Thanks for the answers! The whole reason I'm trying to use this warning is
to detect possible RTTI problems with shared libraries (see
GCC Frequently Asked Questions - GNU Project).

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)

So, your suggestion is to have an anonymous namespace around these classes?
I'll give it a try.

I /think/ that should be a reasonable solution but I don't know if
Clang actually suppresses the warning (& better yet, can/does emit the
vtable strongly) in that case. I'd at least look into/ask around if
it's reasonable to fix it so Clang does this if it doesn't already
(excuse the vague/defensive language - I'm just not 100% sure so
that's all very much "pending further discussion")

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.

OK. So in this case I'll have to fall back to add a default implementation
in a source file, and add that source file to the module/shared library.
Which kind of kills the whole pure virtual interface stuff...

You already need to define the dtor (even if it's pure virtual) anyway
- so it's just a matter of putting that definition non-inline. (if,
for runtime performance reasons, you don't want the dtor to be
non-inline, you can define some arbitrary private virtual non-inline
function to act as the vtable anchor)

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.

We use several modules (shared libraries, frameworks).
The hidden attributes marks a class invisible for the executable or other
modules, and the compiler knows about this, as it is a language feature. So
it can also be a compile time issue.

Right - but even if it's not visible outside the module, it's still
visible across translation units within the module so you still have
the weak/strong differences (object file bloat, link time
deduplication) that -Wweak-vtables is trying to tell you about.