[Development] What kind of airplane we want to build?
Thiago Macieira
thiago.macieira at intel.com
Sat Jan 23 01:39:47 CET 2016
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
More information about the Development
mailing list