[Development] Wishes for C++ standard or compilers

[Marc Mutz]

On Monday 20 March 2017 22:19:11 Thiago Macieira wrote:
> Em sábado, 18 de março de 2017, às 14:20:49 PDT, Thiago Macieira escreveu:
> > == Containers ==
> > 
> > And then there's what to do with the containers. Here's where Marc's
> > opinion and mine differ considerably. Aside from the need to maintain
> > source compatibility, I feel like we should keep our containers and keep
> > implicit sharing (same solution as for QString). We know COW can be a
> > pessimisation for performance-sentive code, but the question is whether
> > it is so for regular developers who don't know how to write
> > performance-sensitive code. If developers will make mistakes, can we
> > reduce the impact?
> 
> Here's another wish that I remembered: destructive move a.k.a. relocation.
> 
> The destructive move is a special case of move in which the source is also
> detroyed in the process, as opposed to the regular move in which its
> contents get moved but the destructor is still called and the object is
> still in a valid (but unspecified) state.
> 
> Then we have an even more special case of destructive move: trivial
> destructive move (trivial relocation), which is just a memcpy. A type with
> trivial move constructor and trivial destructor is trivially relocatable
> too, since the trivial destructor does nothing and the trivial move
> constructor is memcpy. However, the trick is to implement the relocation
> for non-trivial types.
> 
> Note that this needs the discussion on the lifetime of trivial types to be
> finished.

+1

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.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts