[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