[Development] What's Q_PRIMITIVE_TYPE for?

[Lars Knoll]

> On 13 Nov 2020, at 09:06, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> 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 would hope that we’ll get mechanism to move them and help from the compiler  and/or C++ standard here. This is especially needed for relocatable objects, as that makes a huge performance difference, but make a big difference for primitive types as well.
> 
>>> 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?

How likely is that though? I’d say let’s fix it when it happens. It’s possible to restrict when to apply those optimisations in a later minor/patch release.

Cheers,
Lars