[Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Thiago Macieira thiago.macieira at intel.com
Sun Aug 9 19:52:25 CEST 2015


On Sunday 09 August 2015 13:58:12 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > On Sunday 09 August 2015 03:26:33 Kevin Kofler wrote:
> >> Marc Mutz wrote:
> >> > On Friday 07 August 2015 19:41:07 Kuba Ober wrote:
> >> >> How about making such traits explicitly necessary? People would then
> >> >> have to learn about them. As a user, I wouldn't mind - the compiler
> >> >> would pick it all up for me.
> >> > 
> >> > An option for Qt 6, but for Qt 5, it would be a source-incompatible
> >> > change.
> >> 
> >> Or, since we're already discussing source-incompatible changes, how about
> >> defaulting to Q_MOVABLE_TYPE? It's the common case, and if you screw up,
> >> you'll notice it crash and burn pretty quickly.
> > 
> > No can do.
> 
> Care to elaborate? 

Yeah, I don't think "dangerous by default" is a good practice. We err on the 
side of caution. If you want better performance, you apply optimisations to 
the safe code.

This problem is also known as "premature optimisation".

> > Please see the C++17 proposal of destructive moves instead.
> 
> It took 4 years for Qt to agree to require a limited subset of C++11, so,
> realistically, C++17 features are not likely to end up used (everywhere, at
> least) before at least 2021.

Given enough incentive, we can start using something sooner. We did begin 
using std::is_enum (hidden behind Q_ISENUM) because it was worth it. So if all 
we need is a trait, we'll figure it out.

> I guess it will also require good compiler optimization to be as effective
> as a memmove operating on the whole vector. (Basically, the compiler needs
> to detect that you are memmoving a whole vector and convert it to a
> memmove.)

That is exactly what this proposal is not about. If you have a trait that 
indicates your object type is trivially destrucible movable (a.k.a. "trivially 
relocatable"), then we won't do memmove at all. We'll just do realloc, period.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list