dllexport produces incorrect warning from Clang Code Model
-
When exporting a class derived from
QObject
from a shared library using the***SHARED_EXPORT
macro that expands todllexport/dllimport
the Clang Code Model issues following warning on a class:warning: 'SomeClass' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit
The minimal example:
In *.pro
DEFINES += SOMECLASSLIB_LIBRARY
In SomeClass.h
#if defined(SOMECLASSLIB_LIBRARY) # define SOMECLASSLIB_EXPORT Q_DECL_EXPORT #else # define SOMECLASSLIB_EXPORT Q_DECL_IMPORT #endif class SOMECLASSLIB_EXPORT SomeClass : public QObject { Q_OBJECT public: virtual ~SomeClass(); //defined in cpp };
In SomeClass.cpp
SomeClass::~SomeClass() {}
Is this a bug in Clang, Qt, Windows or something else? The issue is the export macro.
-
@Resurr3ction What that warning is saying is that there are no functions that aren't defined inline. More than likely the compiler optimized your no-code destructor into an inline function.
Try changing it's definition in the cpp file to:
SomeClass::~SomeClass() { }
And if that fails, add some code or another function. It should generate the vtable just fine as long as your class actually does something to export.
-
Unfortunately this is not the problem. Regardless of how many virtual functions are defined (or not) the warning only goes away if I remove the exporting macro. Therefore I conclude that the problem is with Clang handling the export macro and not the vtable being emitted every time. Unless of course exporting from shared library meant that vtable IS emitted in every translation unit. Then the warning would be technically correct but there is nothing one can do about it...
-
@Resurr3ction
Add an out-of-line method before the destructor, that should make it disappear I think. e.g.class SOMECLASSLIB_EXPORT SomeClass : public QObject { Q_OBJECT public: SomeClass(QObject * = Q_NULLPTR); virtual ~SomeClass(); };
myclass.cpp
SomeClass(QObject * parent) : QObject(parent) { // Just the trivial constructor } SomeClass::~SomeClass() { }
-
@kshegunov Well yes, that is it. I used inherited constructor so first real method was the virtual destructor. Thank you!
-
And if that fails, add some code or another function. It should generate the vtable just fine as long as your class actually does something to export.
So like I said add some code/another function for your vtable to generate properly, lol. :) I just wasn't as succinct as @kshegunov.
-
@ambershark said in dllexport produces incorrect warning from Clang Code Model:
More than likely the compiler optimized your no-code destructor into an inline function.
This, however, is incorrect. Virtual methods can't be inlined, ever.
-
@kshegunov said in dllexport produces incorrect warning from Clang Code Model:
@ambershark said in dllexport produces incorrect warning from Clang Code Model:
More than likely the compiler optimized your no-code destructor into an inline function.
This, however, is incorrect. Virtual methods can't be inlined, ever.
I did not know that. Then again I don't think I've ever tried to inline a virtual as it really wouldn't make sense. Learn something new everyday. :)
-
I meant that you can write as an inline (in the class declaration) or not, but the compiler can never inline the code (as it's a call trough the virtual table). And of course
virtual
andinline
are mutually exclusive as modifiers in the declaration.Basically:
class A { virtual void a() {} }
is the same as
class A { virtual void a(); } void A::a() { }