[Development] QThread::create mandatory in Qt 6?
QThread::create is still behind a few #ifdefs in Qt 6. It requires: 1) a configure-time check for C++11 std::future and std::async 2) a compile-time check for C++14 std::invoke and some C++14 language features #1 enables the create() function at all; #2 enables the ability to pass a callable that takes argumentst and those extra arguments to create() . During Qt 5 that made sense because we only required C++11. Qt 6 requires C++17 core language. Do we also want to require C++17 standard library? Or at least the C++14 standard library? Or even the C++11 library? The reason I ask is that there is one platform in the CI that is currently failing to compile some QThread::create-using code because even #1 is failing. That is, it doesn't have complete C++11 standard library support (or the cmake test is failing for other reasons). Do we want to kick it to the curb? I think we should require #1 and #2 to pass and simply remove the tests. Simply make qthread.h assume they are there and let the build fail if not. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
On Friday, 13 November 2020 11:24:49 PST Sune Vuorela wrote: > I also think it is sane to 1) EOL Qt Chooser. As the qtchooser maintainer. I am declaring it EOL and have closed the remaining open tasks. I hereby also resign maintaining it too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
On 2020-11-02, Lars Knoll wrote: > I honestly don't think renaming all our binaries is an option, certainly not > that late in the process. We’ve had Qt 4 and Qt 5 co-installed for a long > time as well and while that might not be perfect it was working. > > And qtchooser has been working nicely for me (Ubuntu at least uses it). I pushed quite hard to use it Debian (and ubuntu inherited it), but it is also a tool that from a packaging perspective gets in the way. Gives surprises. and weird systems for people. I also think it is sane to 1) EOL Qt Chooser. 2) Add version numbers to all public facing executables. (See also e.g. python2 vs python3). and 3) and do it in Qt so that distros are constistent with eachother, with windows, with mac, and with the Qt documentation. Oh. And I'm surprised by the Qt-people sudden love of QtChooser - I had a quite hard battle getting just rudimentary support into Creator to support the Qt's setup there. /Sune ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
Hi! On Thu, 12 Nov 2020 at 20:29, Lisandro Damián Nicanor Pérez Meyer wrote: > > Hi! > > On Wed, 11 Nov 2020 at 12:55, Thiago Macieira > wrote: > > > > On Monday, 9 November 2020 09:57:13 PST Lisandro Damián Nicanor Pérez Meyer > > wrote: > > > Seriously, we have discussed this before, and we kind of agreed that > > > user-facing applications should either be really backwards compatible > > > or should have the tool suffixed with the qt version. Whatever other > > > option is just pain for maintainers, be it trough qtchooser or by > > > letting us renaming tools ourselves. > > > > Lisandro, Kevin, other packagers in the list: > > > > May I suggest you get together and make a proposal? If you can get a patch > > into Gerrit, great. If not, then post the cmake command-line that Linux > > distributions will use. We need the distributions to be consistent with each > > other. > > > > Post to this list what the Qt 6 Linux distributions packages will install > > and > > what the layout will be. Whether the default builds do the same or not is > > irrelevant. It's your choice and can go against the default build. > > > > This is important for KDE Frameworks 6 and other software that mostly builds > > from distro packages will likely adopt for its reference documentation. > > I like the idea. I have not touched Qt 6 yet (I'm very sadly not going > to be able to maintain it) but I think this is actually a nice thing > to do. I'll reach my co-maintainers and ask there. Kevin: can you do > the same? I've discussed this with Dmitry Shachnev and the simplest way to "solve" this would be to ship binaries in /usr/lib/qt6/bin/foo and have /usr/bin/foo-qt6 symlinks to those. Projects using CMake to build will have no issues at all. If KDE people need to call a user-facing application they might get the path from CMake too. Note that I used the -qt6 suffix here because I think that's what most distros have been doing, but we have no opposition to any other suffix scheme if necessary. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What's Q_PRIMITIVE_TYPE for?
On Friday, 13 November 2020 00:19:41 PST Lars Knoll wrote: > 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. For relocating, I'm sure the language will provide a solution and compilers will likely give us a grace period to adjust. I don't think there are many people (I don't know any) that oppose the idea of relocating objects, even if they oppose the actual solution chosen to do that (like a core language extension to provide a destructive move constructor or a moving destructor). Actual C++ primitive types won't be affected because they are trivial. My point again is that we are doing that for non-trivial types. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What's Q_PRIMITIVE_TYPE for?
On Thu, 12 Nov 2020 at 17:11, Lars Knoll wrote:
> Language Lawyer Hat: is_trivial is the wrong type trait when it comes to
> detect trivial copiability anyhow, example:
>
> struct S { int i; S operator=(const S &)=delete; };
>
> is trivial and not copy assignable. Isn't C++ a fun language to work with...
> :P
>
>
> Sigh… is_trival implies is_trivially_copyable. That one implies
> https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable, which implies
> that all “eligible” copy/move constructor and assignment operators are
> trivial. But they don’t disallow deleting them (as that makes the operator
> not eligible).
>
> So what are the correct traits then? Sounds like “is_trivially_copyable and
> no deleted copy/move operators” is about what we need :/
Well, even libstdc++ uses is_trivial for some memcpy optimizations,
but that chooses strictly fewer types than is_trivially_copyable
would. However, the optimizations I'm talking about are in
std::{uninitialized_,}copy - and there's checks for more than just
is_trivial, because
the really fun part of is_trivial and is_trivially_copyable is that
they tell you whether some sort of memcpy is valid, but that might
not be the kind of memcpy you're doing. Meaning that, when you want to
memcpy over raw storage, you should check
is_trivially_copy_constructible, and if you're memcpying over existing
objects, you should check is_trivially_copy_assignable.
Those traits will check whether the relevant operation is well-formed,
including "not deleted".
Using is_trivially_copy_constructible and is_trivially_copy_assignable
thus also avoids the problem Thiago mentioned, i.e.
UB when skipping a non-trivial or deleted operation. However, in our
code, it's not so simple, because in some cases
we *do* bit-blast non-trivial types, because the standard doesn't
provide relocatability.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] What's Q_PRIMITIVE_TYPE for?
> On 13 Nov 2020, at 09:06, Thiago Macieira 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What's Q_PRIMITIVE_TYPE for?
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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
