> On 17 Jul 2020, at 17:30, Thiago Macieira <thiago.macie...@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@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development