[Development] RFD: plugins vs QStringLiterals

[Oswald Buddenhagen]

On Thu, Nov 05, 2015 at 06:23:37PM +0100, Robin Burchell wrote:
> On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote:
> > > 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).
> 
> Is the problem only apparent inside of plugins? Do we have a way to
> detect whether someone is building plugin code at build time? (CONFIG +=
> plugin for qmake, I guess?) If so, couldn't the behaviour of
> QStringLiteral differ for code inside of plugins, to that outside of
> them?
> 
you can also have plugin code which is perfectly safe.
only a kinda perfect static analysis would give you a verdict about the
safety of your code.

On Thu, Nov 05, 2015 at 06:23:49PM +0100, Milian Wolff wrote:
> 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:
> > > 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.
>
uhm, so? you can still do something "stupid" with QSL in a tight loop.