On terça-feira, 30 de janeiro de 2018 13:51:55 PST René J. V. Bertin wrote: > Apparently moc doesn't really know how to handle `QCache<QRegExpEngineKey, > QRegExpEngine>` as the primary class signature. I hope that the difference > in primary parent class between QT_BOOTSTRAPPED and normal mode won't lead > to conflicts?
It's not that it doesn't know. It doesn't want to: QObject must always be the first parent (directly or indirectly). There can't be conflicts because bootstrapped code is never mixed with non- bootstrapped. > Something else: is there a point to using QBasicMutex? I understand it's > supposed to be faster, but QMutexLocker doesn't have a ctor for the class so > it probably gets promoted to a QMutex. Don't you lose the performance > advantage that way, and in addition pay for the conversion? QBasicMutex is POD, unlike QMutex, so it's always statically initialised (except with buggy compilers, like MSVC 2017). QMutex requires a constructor to be run before you can use it, which could lead to use before the construction if some other dynamic initialiser called into this code. It shouldn't lead to any visible consequences because QMutex's constructor will fill it with zeroes, but it's UB. You do lose a bit in performance if you call QMutex::lock() on a QBasicMutex: it makes an out-of-line call, instead of inlining the test-and-set. If not too hard, call .lock() and .unlock() directly. Technically, it's also UB to call QMutex::lock() on an object that isn't a QMutex. But we get away with it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
