Failing qobject_cast

? Offline

qobject_cast should be safe over DLL boundaries - that's at least what the docs state. You did not answer whether the Surface_mesh class is based on QObject too?

? Offline

Hi Volker,

Indeed, that's why I was using qobject_cast at a certain point (and going back to it right now)

And to answer your question, yes it is:
@
class SurfaceMeshModel : public Model, public Surface_mesh{
Q_OBJECT
Q_INTERFACES(Model)
...
@

? Offline

That was clear, SurfaceMeshModel inherits Model which eventually inherits QObject.

The question is, does your second base class, Surface_mesh, inherit QObject too (directly or indirectly) - i.e. what's the class hierarchy for the Surface_mesh class?

? Offline

Oh sorry, misunderstood your question. Surface_mesh is an external library and not Qt, so no, it doesn't know anything about Qt at all..

? Offline

Ok. That's good. It's not allowed to inherit QObject via two different paths.

So, what's the output of that little debug loop I pasted earlier?

? Offline

And this is the output of this snippet:

@
const QMetaObject *mo = model->metaObject();
qDebug() << "Hierarchy: ";
while(mo) {
qDebug() << " " << mo->className();
mo = mo->superClass();
}
@

Output:
@
Hierarchy:
SurfaceMeshModel
Model
QObject
MASSIVE FAIL.. TERMINATING
@

? Offline

This is really strange. Can you boil down the code to small, yet complete test case that demonstrates the error? I don't have any clue, whats going wrong here. BTW: what operating system are you on?

? Offline

I am on OSX Lion. I isolated the problem even more. Look at the snippet below:

@
SurfaceMeshModel* model = new SurfaceMeshModel(path);

Model* retval = qobject_cast<Model*>(model);
qDebug() << "Conversion Mesh=>Model: " << (retval?"success":"failed");

SurfaceMeshModel* mesh = qobject_cast<SurfaceMeshModel*>(retval);
qDebug() << "Conversion Model=>Mesh: " << (mesh?"success":"failed");
@

And the output is ...
@
Conversion Mesh=>Model: success
Conversion Model=>Mesh: failed
@

? Offline

And now I just replaced the qobject_cast with a dynamic cast. I get a "success, success" in the test above, but a fail when it goes across the DLL boundaries (the snipped above was within the boundaries of a single compiled element).

? Offline

Just for curiosity, what's the output of

@
qDebug() << "model :" << model;
qDebug() << "retval:" << retval;
qDebug() << "mesh :" << mesh;
@

? Offline

By using both qobject_cast:

@
Conversion Mesh=>Model: success
Conversion Model=>Mesh: failed
model : SurfaceMeshModel(0x1023b3fc0)
retval: SurfaceMeshModel(0x1023b3fc0)
mesh : QObject(0x0)
@

? Offline

Weird. It's completely weird.

Just a another blind guess: may it be, that you happen to load two different versions of the Qt libs via the two libraries (resp. your app and library)? This may cause trouble too.

You can check this with the otool tool on the mac and some dyld debug settings:

@
export DYLD_PRINT_LIBRARIES=1
/path/to/your/Program.app/Contents/MacOS/Program 2>LOG-libraries.txt
unset DYLD_PRINT_LIBRARIES
@

Then check LOG-libraries.txt for the loaded Qt libraries:

@
grep Qt LOG-libraries.txt
@

It must not print libraries from different paths.

? Offline

I think I am approaching the esoteric here :)

These two are defined in the same header that will compile into
the same library:
@
class LOCSurfaceMeshModel : public Model, public Surface_mesh{
Q_OBJECT
Q_INTERFACES(Model)
public:
LOCSurfaceMeshModel(){}
};

class SurfaceMeshModel : public Model, public Surface_mesh{
Q_OBJECT
Q_INTERFACES(Model)
....
};
@

Then this block is executed:

@
{
LOCSurfaceMeshModel* mod = new LOCSurfaceMeshModel();
Model* retval = qobject_cast<Model*>(mod);
qDebug() << "Conversion Mesh=>Model: " << (retval?"success":"failed");
LOCSurfaceMeshModel* mesh = qobject_cast<LOCSurfaceMeshModel*>(retval);
qDebug() << "Conversion Model=>Mesh: " << (mesh?"success":"failed");
}
{
SurfaceMeshModel* mod = new SurfaceMeshModel();
Model* retval = qobject_cast<Model*>(mod);
qDebug() << "Conversion Mesh=>Model: " << (retval?"success":"failed");
SurfaceMeshModel* mesh = qobject_cast<SurfaceMeshModel*>(retval);
qDebug() << "Conversion Model=>Mesh: " << (mesh?"success":"failed");
}
@

And "OBVIOUSLY" the output is...
@
Conversion Mesh=>Model: success
Conversion Model=>Mesh: success
Conversion Mesh=>Model: success
Conversion Model=>Mesh: failed
@

Complete NO-SENSE... Sigh.. I will go by elimination now..
I will strip down the original class to the one that work..

? Offline

So by following the process above I found my error. It was this stray include lying in my runtime subsystem. (there was a time where I turned off the plugin system and did things locally)

@
#include "../lib_surfacemesh/SurfaceMeshModel.h" /// TO BE REMOVED
@

I wish I could offer more intuition on WHY it was causing the whole dynamic casting to fail.. But I seriously have no clue!

NOTE: this fixed the cast/uncast ONLY when I was trying my test code. If an object is created from a plugin, casted to the interface object and casted back to the subclass in a second plugin... the cast still fails... triple sigh...

? Offline

Let me use a small diagram to describe what is happening:
"Diagram":https://docs.google.com/drawings/d/1Jp-wpPuFTCvsC-3ovRmZXlRj93U0TfS7urxpfkLZPEc/edit

The core runtime loads the plugins1/2

Everything else is statically linked to Core Runtime

Core runtime calls plugin1 to generate an instance of SurfaceMeshModel

(note: plugin1 casts this instance to the more general Model which is the only thing runtime knows about as the diagram shows)

Core runtime calls plugin2, which receives Model* and needs to cast it back down to SurfaceMeshModel <=== This is the failure point

What I mentioned above is that now the cast/uncast of an object within a single plugin works well. But if I create an object and pass it to another plugin... that's where the casting fails...

Do you see any fault with my design?

Andrea

? Offline

Your SurfaceMeshModel must be defined ONLY once in your application. If Plugin1 and Plugin2 need to know and use SurfaceMeshModel and even more pass instances of it, then you need an extra shared library that will offer it to the plugins. You must then link both your plugins to that library.
If you compile the SurfaceMeshModel in each plugin, it will work locally in that plugin but not outside of the plugin boundaries using qobject_cast.
The reason is that each plugin will have its own QMetaObject (because of the MOCed Q_OBJECT macro) for that SurfaceMeshModel class. And from a Qt standpoint two classes with different QMetaObject instances are not the same class, even if they have the exact same interface and all.
However, I am sure it would work flawlessly with a static_cast as the compiler has generated the same code and memory layout in both plugins but this is not a good practice in general.
You need an extra shared library (that your Core runtime does not need to know as far as it is concerned).

? Offline

Hey rcari, fact is.. I did create an extra shared library doing exactly what you say!
I am building some example code to show you guys. But as you say, within both plugins I have a "pri" file that loads the SurfaceMeshModel class:

@
macx:POST_TARGETDEPS += $$SOURCE_ROOT/libraries/lib_surfacemesh.a
macx:LIBS += -L$$SOURCE_ROOT/libraries -l_surfacemesh
@

And yes, the core library is unaware of this shared (static) library used by both plugins.
Let me see if the static_cast will work, just for the heck of it :)

? Offline

You can't use it as a static lib, it breaks the whole point. The static lib will be fully included in each plugin.
You need a SHARED library (in opposite to STATIC, not as a conceptual shared compilation unit).
Using a SHARED library, when one of the plugins requiring it is loaded, this extra library is loaded as well, when the second plugin is loaded, the extra library is already loaded and they SHARE that code.
See http://en.wikipedia.org/wiki/Library_(computing)

? Offline

Here you go :) Rcari I think you solved the problem. What you are saying makes perfect sense!

Indeed, static_cast did work (pointer was not null), but when I then tried to use the casted object I got some wacky runtime error!!

I will let you know if changing to dynamic library will solve it. Thank you so much for your input :)

? Offline

LaCie? I think I have a usb key in the shape of a real key from your company :)