[Development] RFD: plugins vs QStringLiterals

[Oswald Buddenhagen]

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

>  b) without
> 
> Problem: performance impact, complexity of the atom/quark solution.
> 
to lessen the performance impact, we could have a #define to control the
construction behavior of QSL at compile time. i'm not quite sure whether
to make that opt-in or opt-out (safety vs. performance).