On Thursday 21 November 2024 23:14:30 Pacific Standard Time Schimkowitsch Robert wrote: > Hi Volker, > > do you think that the language (let's say up to 23, because constexpr could > be a conditional macro anyway) would even allow making constexpr useful, > bigger portions such as > - basic implicit sharing mechanism > - basic usage of QString > - basic usage of QList?
Yes, we looked into that but that caused the build to break with Clang, because it changes how aggressive it instantiates templates in QArrayDataPointer if they are constexpr. That causes the build to break for non-constexpr contexts. Right now, this work is postponed until we figure out what we can do. One idea is to support constexpr QString and QByteArray, and maybe QLists of trivial types, but not for anything else. > These are so common in our codebase that without them, only a relatively few > functions can ever be made constexpr. You will be able to create and destroy QString and QByteArray, find out if they are empty or not, get the pointer to the data, but not call almost any other methods in them. > Herb Sutter highlighted constexpr as a way to increase programming language > safety in his recent keynote at Meeting C++. Things like making a runtime > function constexpr, so you can, at compile time, check for UB using > static_asserts or such when feeding it with various ranges of values (min, > max, zero, empty list,...). Now I'm thinking about how we could apply those > ideas in real code - and Qt mostly stops us from doing that, right there > and then. That's a fallacy. The fact that you can do it under constexpr doesn't magically make the same usage safe when not under constexpr. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
