Am 23.06.2014 um 19:13 schrieb Till Oliver Knoll till.oliver.kn...@gmail.com:
...
And I /still/ think that was exactly one of the (many) selling points of
using the Qt Meta Object over the RTTI, because the later is /not/ guaranteed
to work across DLLs when it comes to dynamic casting... it
Am 23.06.2014 um 03:11 schrieb Thiago Macieira thiago.macie...@intel.com:
... In QObject and qobject_cast's case, it's the
meta object (the output of moc); for RTTI and dynamic cast, it's the
typeinfo.
Each must exist in a single library.
Not sure whether I fully understand your [runtime
Em seg 23 jun 2014, às 12:08:05, Till Oliver Knoll escreveu:
Am 23.06.2014 um 03:11 schrieb Thiago Macieira thiago.macie...@intel.com:
... In QObject and qobject_cast's case, it's the
meta object (the output of moc); for RTTI and dynamic cast, it's the
typeinfo. Each must exist in a single
Am 23.06.2014 um 18:06 schrieb Thiago Macieira thiago.macie...@intel.com:
Em seg 23 jun 2014, às 12:08:05, Till Oliver Knoll escreveu:
Am 23.06.2014 um 03:11 schrieb Thiago Macieira thiago.macie...@intel.com:
... In QObject and qobject_cast's case, it's the
meta object (the output of moc);
Em seg 23 jun 2014, às 19:13:41, Till Oliver Knoll escreveu:
Am 23.06.2014 um 18:06 schrieb Thiago Macieira thiago.macie...@intel.com:
Em seg 23 jun 2014, às 12:08:05, Till Oliver Knoll escreveu:
Am 23.06.2014 um 03:11 schrieb Thiago Macieira
thiago.macie...@intel.com:
... In QObject and
If all of the classes are QObjects, then qobject_cast() should be used
instead of dynamic_cast, which is not guaranteed to work across library
boundaries.
___
Interest mailing list
Interest@qt-project.org
Em dom 22 jun 2014, às 14:56:43, Alan Ezust escreveu:
If all of the classes are QObjects, then qobject_cast() should be used
instead of dynamic_cast, which is not guaranteed to work across library
boundaries.
It has the same requirements as QObject: there needs to be something anchoring
the
Hi,
I would like to implement a plugin system in my app and I'm totally
ignorant of dynamic library mechanisms. So I'm trying with a QPlugin. I'm
using Qt 4.8.5, gcc 4.8.0 mingw64.
The question is : can RTTI work between the plugin and the app?
I will define and include these headers in both
Den 18-06-2014 15:20, Etienne Sandré-Chardonnal skrev:
Hi,
I would like to implement a plugin system in my app and I'm totally
ignorant of dynamic library mechanisms. So I'm trying with a QPlugin.
I'm using Qt 4.8.5, gcc 4.8.0 mingw64.
The question is : can RTTI work between the plugin and
Em qua 18 jun 2014, às 15:20:03, Etienne Sandré-Chardonnal escreveu:
Hi,
I would like to implement a plugin system in my app and I'm totally
ignorant of dynamic library mechanisms. So I'm trying with a QPlugin. I'm
using Qt 4.8.5, gcc 4.8.0 mingw64.
The question is : can RTTI work between
Em qua 18 jun 2014, às 15:32:51, Bo Thorsen escreveu:
You can use a static library, but then stuff like singletons won't work
reliably.
You can't use a static library for RTTI.
In order to get the RTTI to work, the class's typeinfo needs to be in a single
place. On Windows, due to the DLL
Which defeats the purpose of the plugin, which should define a subclass of
a base class common between plugins (and app).
Can I define the base class in a separate library, dynamically linked with
every plugin the app?
Etienne
Will the dynamic_cast work? Is there a special way to
Den 18-06-2014 17:31, Etienne Sandré-Chardonnal skrev:
Which defeats the purpose of the plugin, which should define a subclass
of a base class common between plugins (and app).
Can I define the base class in a separate library, dynamically linked
with every plugin the app?
Yes, that's
Then the plugin will derive from one of the DerivedX classes, and provide
a method in the interface which will list its implemented derived class
names as strings, and provide a factory for them returning Base* objects.
Then, the app will dynamic_cast these pointers to DerivedA, DerivedB,
14 matches
Mail list logo
