On Thursday 07 July 2016 09:25:18 Martin Smith wrote: > How about a merger of options 3 & 4 for Qt 6.0? A QtSTL that combines the > ease of use of the Qt collections with the efficiency of STL algorithms.
Yes, for Qt 6, a template that takes an STL API and provides the Qt methods on it is something I'd welcome. But not to be required in internal implementation, as is implied in this thread. Game devs on CppCon report that compilers have problems fully inlining STL container use where it should be fully inlined (I myself ran into such a case: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621) We use STL containers because they are more friendly to the compiler[1], which equates to faster and/or smaller, adding more stuff on top will make them slower, unless we fiddle with compiler-specific settings such as inlining depths, if that helps at all (it didn't for the bug report linked above). Thanks, Marc [1] I don't think everyone here knows that every asm volatile as part of a QAtomic operation makes the compiler forget everything it knows about memory / value propagation, ie. it writes back registers to memory before and needs to re-load values from memory after the asm volatile. It gets better if QAtomic is backed by std::atomic, but even on x86, those ops aren't cheap. A cmpxchg takes more than 200 cycles to complete, if the memory is off-socket, compared to ≤ 0.5 cycles for a reg-reg operation. That's only the case if the object is actually shared among processors, but it shows just how bad it can be. On-die, it's still something like 20 cycles. -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development