[Development] Wishes for C++ standard or compilers

[Olivier Goffart]

On Mittwoch, 29. März 2017 11:53:16 CEST Ville Voutilainen wrote:
> On 29 March 2017 at 12:49, Marc Mutz <marc.mutz at kdab.com> wrote:
> > This is probably one of the most important things. Ville asked on std-
> > proposals to show hard numbers. You don't need hard numbers. You just need
> > to superficially look at QVector<QString>. The compiler generally cannot
> > proove that the call to QArrayData::deallocate() can be dropped from the
> > QString dtor. It will always emit the atomic lock;sub and the call to
> > deallocate(), even though the move ctor is inline and sets the d-pointer
> > to sharedNull(). I have tried many things over the past year or so, incl.
> > Q_ASSUME(!ref == -1) in sharedNull() and explicitly checking for that
> > same condition in the QString dtor. It just doesn't help.
> > 
> > This is an example of the WTF missed-optimisation that Chandler presented
> > at MeetingC++ 2016: https://www.youtube.com/watch?v=s4wnuiCwTGU
> > 
> > Only difference: we need it for thousands of items, not just four.
> 
> The hard number we still need is this:
> 1) how much of a performance difference does a destructive move make
> 
> The softer numbers we need are these:
> a) how many types benefit from it
> b) how often are those types used
> c) what are the practical performance improvements, assuming that the
> hard number (1)
> gave us a benchmark number.
> 
> If "you don't need hard numbers", be prepared to live with a C++ that
> doesn't have
> a destructive move. Assuming that everyone in the committee finds its
> motivation obviously sound is a losing strategy, as is assuming that many
> people in the committee
> are aware of how destructive move helps implicit-sharing containers.

A destructive move has actually already been proposed: N4158
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4158.pdf
This was from 2014 and proposed std::uninitialized_destructive_move
Later, in 2015 there was N4393 that references it
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4393.pdf
But I don't know if anything went further than that.

Can we live without it in Qt? 
I would like to point out the the optimization we do currently with QVector 
and Q_DECLARE_TYPEINFO(Q_MOVABLE) is technically an undefined behavior, I 
think. (I believe a sanitizer using shadow memory to check the lifetime of 
objects would catch this. It's not allowed to use memcpy on types that are not 
trivially copyable)
So Qt currently invoke quite a lot of UB. And having a standard way to do that 
would be great.

-- 
Olivier