[Development] QProperty and library coding guide

[Thiago Macieira]

On Friday, 17 July 2020 00:25:04 PDT Lars Knoll wrote:
> Yes, it can and it does work. And it’s what we should be doing on compilers
> that support [[no_unique_address]].

The problem is that you can't change your mind, since it affects binary 
compatibility. See https://godbolt.org/z/oExfzP:

 struct Union
{
    struct Empty {};
    union {
        Empty e;
    };
    void *dummy;
};
struct NoUniqueAddress
{
    struct Empty {};
    [[no_unique_address]] Empty e;
    void *dummy;
};

These two structures do not have the same size and the offset of "dummy" in 
each is also different. That means the choice of using [[no_unique_address]] 
or not using it must be made RIGHT NOW and cannot be changed.

Let's say we're going to enable it now for Linux. Ok, good. Please make EVERY 
SINGLE Qt build and user's application build unconditionally use 
[[no_unique_address]] from now until 2028. Regardless of compiler choice (GCC, 
Clang and ICC), compiler version and build flags.

Here's the patch. Add qglobal.h:
#if defined(Q_OS_LINUX) && !__has_cpp_attribute(no_unique_address)
#  error "Your compiler is too old."
#  error "Please upgrade so it supports [[no_unique_address]]."
#endif

I will give a +2 for this patch, since I prefer it. That means adding 
properties doesn't imply an extra 8 bytes per class in the hierarchy. Imagine 
a user class hierarcy like QSctpSocket -> QTcpSocket -> QAbstractSocket -> 
QIODevice -> QObject. If each class has properties, that adds 40 bytes to the 
full size of QSctpSocket.

[Yes, I know Qt-based classes should just put their properties in the d 
pointer, but users don't usually have d pointers]
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products