[Development] RFD: plugins vs QStringLiterals
milian.wolff at kdab.com
Thu Nov 5 18:23:49 CET 2015
On Donnerstag, 5. November 2015 18:13:36 CET Oswald Buddenhagen wrote:
> On Thu, Nov 05, 2015 at 11:44:33AM -0500, Thiago Macieira wrote:
> > Alternative: force QPluginLoader / QFactoryLoader to fake unloading but
> > not
> > really unload.
> you already did that quite a while ago. was it reverted? or never
> > I've said in the past that unloading plugins is a bad idea in C++. The
> > case
> > then was that it's easy to leave objects of a polymorphic class type whose
> > virtual table is located in the unloaded plugin. This is not very
> > different, since the QStringLiteral's data is also global data not
> > expected to disappeaar.
> the generic c++ case isn't that bad, because the user can reasonably
> control the lifetime of objects and delete them before unloading
> associated plugins.
> obviously, qt's implicit sharing takes away this control, which is
> exactly the problem.
> > 2) Deep-copy the QStringLiterals
> > a) with atom/quark
> this sounds like it could be quite horrible (when people rely on cheap
> instantiation, e.g., for comparisons).
When you load a plugin, or compile a QRegExp, or use DBUS, or ... then the
cost of these operations easily dwarfs the string heap allocation. So this is
not that bad, imo.
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5903 bytes
Desc: not available
More information about the Development