[Development] What kind of airplane we want to build?

[charleyb123 .]

Thiago sayeth:

> <snip>,
> 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?
>

That would have been handy for a previous project, as we had the same
codebase deploying to multiple architectures and we effectively had to do
that ourselves -- we preferred QAtomics (because of the better API), but
needed to wrap std::atomic for our deployment to one ARM platform.

So, we made our own wrapper atomic class with the Qt interface, but had an
#ifdef...#endif to wrap std::atomic for one platform.  Worked fine (it's
now a preferred pattern).


> > > 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.
>

Agree here also, and with other comments in the thread regarding
"not-much-love" for STL API choices/semantics.

IMHO:

(1) Most programmers don't even know about the STL algorithms.

(2) Most programmers have a hard time conceptualizing what the STL
algorithms are "supposed to do", even when looking right at them, after
they are correctly employed in working code.

(3) STL API conventions and volatility across versions are ... unfortunate.

(4) Due to 1-3, many informed programmers remain unconvinced of the value
of even bothering to increase STL algorithm adoption.  (I think this is
disappointing, but concede it to be a rational response by many teams.)

I really think the, "convenience API" is worth a *lot*.  Even just wrapping
<algorithm> with Qt semantics is worth a ton.  Programmers would actually
*use* those, and *understand* those in code.

Recall that even in on the C++ committee, there is not universal support
for the ".begin(), .end()" where two parameters are required to iterate a
single container (e.g., web search for, "Iterators Must Go", Niebler's new
iterators work, proposals for future modified APIs for parallel-iteration
of container elements).

So, this would add another interesting motivation (and I'm seriously going
to, "get out the popcorn" to watch the events unfold as I listen to the
wailing and lamenting and gnashing-of-teeth as...)

(5) In the not-too-distant future, the existing STL iterators API may be
deprecated in favor of new iterator conventions.

That sure is a lot of code to migrate, and it would be nice to have a
convenience API to adopt.

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160123/14373ae2/attachment.html>