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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
