dllexport produces incorrect warning from Clang Code Model

Resurr3ction · 21 Dec 2016, 18:42

When exporting a class derived from QObject from a shared library using the ***SHARED_EXPORT macro that expands to dllexport/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.

ambershark · 22 Dec 2016, 18:50

@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.

Resurr3ction · 22 Dec 2016, 07:49

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...

kshegunov · wrote on 22 Dec 2016, 07:49

@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()
{
}

Resurr3ction · 22 Dec 2016, 18:39

@kshegunov Well yes, that is it. I used inherited constructor so first real method was the virtual destructor. Thank you!

ambershark · wrote on 22 Dec 2016, 18:39

@Resurr3ction

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.

kshegunov · 22 Dec 2016, 19:00

@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.

ambershark · 22 Dec 2016, 19:35

@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. :)

kshegunov · wrote on 22 Dec 2016, 19:35

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 and inline 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()
{
}