[Development] What's Q_PRIMITIVE_TYPE for?

[Thiago Macieira]

On Thursday, 12 November 2020 23:45:35 PST Lars Knoll wrote:
> Huh? In a release build assertions also expand to nothing. So it does remove
> many checks. Opposed to that, a debug build or one with address sanitiser
> enabled, could check those kind of things more thoroughly.

Sorry, we may be miscommunicating. Let me be clear on what I meant:

Compilers are likely to implement object lifetime tracking in the near future 
and make strict aliasing and dead code elimination passes based on the dynamic 
type of a memory object. This is without extra memory consumption -- it's not 
ASan. Since our containers and the Standard Library's are templates, the 
majority (or entirety) of the code is available for the compiler to make 
analyses of.

Therefore, skipping the proper constructor calls can cause miscompilation in 
the near future. This is what I meant by this paragraph, saying we can ignore 
now, but will need to deal with it.

> > I propose we ignore the lifetime issues *for* *now*. We need a proper
> > language solution to declare objects' lifetime has started when we do
> > either of the three operations above, without loss of performance
> > afforded by the memcpy / memset. So either the language gives us a
> > std::launder-like interface to bless the fait accompli or the compilers
> > give us equivalent performance without such an interface. The relocation
> > of non-trivially copyable types will likely have a language update
> > because the current direction seems to include adding a destructive move
> > operation.

[cut]
> I agree that (1) is probably not be worth it, especially if it means that we
> have to largely cut down on the amount of classes that can be marked as
> primitive by default.
> 
> (2) and (3) are clearly worth it. And for types with trivial copy/move
> operations, the standard even says that memcpy’ing them is ok.

It does, for trivially copyable types. The problem is that Q_DECLARE_TYPEINFO 
with Q_PRIMITIVE_TYPE allows us to apply the same code path to non-trivial 
types. This may run afoul of compiler optimisations in a year or two.

With that in mind, how much risk do we want to accept?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering