[Development] QProperty and library coding guide

Lars Knoll lars.knoll at qt.io
Fri Jul 17 18:41:16 CEST 2020


> On 17 Jul 2020, at 17:30, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> 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.

It’s a choice that has to be made when building Qt, similar to what we had with qreal=float/double in the past.
> 
> 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.

This is only about desktop linux here where we want to define an ABI. And there we can enable it by default I think.
> 
> 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

No, we error out if Qt build ABI and application builds flags are not in sync. If you configure Qt without support for [[no_unique_address]], it’ll work, but it’s a different build.
> 
> 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.

No, it doesn’t. It adds 4/8 bytes (unless your object hierarchy is deeper than 4/8 levels). Since every one of those unions in the hierarchy has an alignment requirement of 1, the property union for QIODevice will be in the byte following the one for QObject.

> 
> [Yes, I know Qt-based classes should just put their properties in the d 
> pointer, but users don't usually have d pointers]

Not sure what you mean here. This is only about our Q_PRIVATE_QPROPERTY, not about the QProperty class.

Cheers,
Lars

> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel System Software Products
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development



More information about the Development mailing list