[Development] RFD: plugins vs QStringLiterals

[Milian Wolff]

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
> integrated?
> 
> > 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
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5903 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20151105/abb1961f/attachment.bin>