On Saturday 23 January 2016 01:12:51 Kevin Kofler wrote: > I wonder why everyone so far agreed on that. So let me dissent: I think > having these things in Qt with Qt-style APIs is a good thing and I don't see > why we should discard our solution for the STL one. At most, where it makes > sense, we could wrap the STL stuff as we're doing with std::atomic.
But I have no plans on extending QAtomicInteger and QAtomicPointer further. There are a couple of missing features that will probably never be implemented: * std::memory_order_consume and std::memory_order_cst * GCC's extension for hidden lock elision * compare_exchange_weak (doesn't affect Intel, so I don't care) * weaker memory model for the failing compare_exchange's reload * atomics on non-integral and non-pointer types, including larger types * volatile support >From my point of view, if you need to go further on atomics, you should just use std::atomic. We could introduce QAtomic which wraps the std::atomic API and adds the Qt- style names. Is it worth it? > > We started some experiments with convenience wrappers for std algorithms > > for use in Qt Creator when we started requiring C++11: > > http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algor > > ithm.h > Interesting. That could be a starting point for a QtAlgorithms successor. Agreed. Instead of reimplementing <algorithm>, expanding them for convenience API. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
