Re: [Interest] Future of constexpr in Qt?
> > Oh, I forgot to add the part that you also need a CI that compiles and runs > with ASan and UBSan. > That's certainly a good idea. Not aware of any UBSan running on MSVC, but nothing wrong with running a parallel CI using clang and UBSan (except...work :-) Kind regards Robert This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. ANDRITZ HYDRO GmbH Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation Firmensitz/ Registered seat: Wien Firmenbuchgericht/ Court of registry: Handelsgericht Wien Firmenbuchnummer/ Company registration: FN 61833 g DVR: 0605077 UID-Nr.: ATU14756806 Thank You ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Future of constexpr in Qt?
On Tuesday 26 November 2024 00:25:45 Pacific Standard Time Schimkowitsch Robert wrote: > The problem with testing UB cases is that the program can do anything, which > means a runtime unit test could succeed even though e.g. I hit a signed > integer overflow. That's why I would consider compile-time tests for such > cases. Oh, I forgot to add the part that you also need a CI that compiles and runs with ASan and UBSan. -- 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
Re: [Interest] Future of constexpr in Qt?
> > That should be done in unit testing, wherever possible. Some > conditions we simply can't test, such as *succeeding* in allocating a > memory block of a size comparable to PTRDIFF_MAX because such a block > is not architecturally possible (on 64-bit machines). As a rule of > thumb for test writers: always test your boundary conditions. The problem with testing UB cases is that the program can do anything, which means a runtime unit test could succeed even though e.g. I hit a signed integer overflow. That's why I would consider compile-time tests for such cases. Kind regards Robert This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. ANDRITZ HYDRO GmbH Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation Firmensitz/ Registered seat: Wien Firmenbuchgericht/ Court of registry: Handelsgericht Wien Firmenbuchnummer/ Company registration: FN 61833 g DVR: 0605077 UID-Nr.: ATU14756806 Thank You ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Future of constexpr in Qt?
On Monday 25 November 2024 00:39:37 Pacific Standard Time Schimkowitsch Robert wrote: > Well, my idea was mostly to test extreme cases in constexpr context, so you > get compiler errors if you overlooked something and e.g. cause unsigned > wraparound when getting passed int_max. That should be done in unit testing, wherever possible. Some conditions we simply can't test, such as *succeeding* in allocating a memory block of a size comparable to PTRDIFF_MAX because such a block is not architecturally possible (on 64-bit machines). As a rule of thumb for test writers: always test your boundary conditions. > But as mentioned above, the number > of useful functions I can write constexpr is probably limited. I believe > Herb rather meant this example to show that it is possible to reduce the > amount of UB allowed in the language. -- 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
Re: [Interest] Future of constexpr in Qt?
Hi and thanks for your replies! > 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. Yeah, I can see this will be of limited use in real life... > > > 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. > Well, my idea was mostly to test extreme cases in constexpr context, so you get compiler errors if you overlooked something and e.g. cause unsigned wraparound when getting passed int_max. But as mentioned above, the number of useful functions I can write constexpr is probably limited. I believe Herb rather meant this example to show that it is possible to reduce the amount of UB allowed in the language. Kind regards Robert This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. ANDRITZ HYDRO GmbH Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation Firmensitz/ Registered seat: Wien Firmenbuchgericht/ Court of registry: Handelsgericht Wien Firmenbuchnummer/ Company registration: FN 61833 g DVR: 0605077 UID-Nr.: ATU14756806 Thank You ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Future of constexpr in Qt?
On Sunday 24 November 2024 05:18:33 Pacific Standard Time Volker Hilsheimer via Interest wrote: > Also, some things that are constexpr in a test might not be constexpr in a > real program. E.g. std::string can only be constexpr as long as the string > fits into whatever size the library uses for its small-string optimization. > As soon as that space is not sufficient, std::string has to allocate using > operator new, and your code will no longer build. C++20 does support dynamic memory allocation at constexpr time https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0784r7.html It must be freed before the evaluation terminates, though. We can detect std::is_constant_evaluated() and use calls to new instead of QArrayData::allocate, but every use of std::is_constant_evaluated() implies that the code that was checked at constexpr time is not the code that is run at runtime. -- 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
Re: [Interest] Future of constexpr in Qt?
> On 22 Nov 2024, at 17:14, Thiago Macieira wrote:
>
> On Thursday 21 November 2024 23:14:30 Pacific Standard Time Schimkowitsch
> Robert wrote:
>> 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.
Also, some things that are constexpr in a test might not be constexpr in a real
program. E.g. std::string can only be constexpr as long as the string fits into
whatever size the library uses for its small-string optimization. As soon as
that space is not sufficient, std::string has to allocate using operator new,
and your code will no longer build.
E.g:
#include
static constexpr std::string data("abcdefghijklmno");
static_assert(data.data() != nullptr, "String must be valid");
See how long that string literal can be until this no longer compiles (and not
because the static assert fails). With both gcc and clang trunk, and
-std=c++26, another character breaks the build - not because of the
static_assert, but because the “data” variable is no longer initialized by a
constant expression.
Volker
PS: which is why for the JNI improvements in the recent Qt releases we cooked
up a true, but very limited, compile-time string type in
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qjnitypes_impl.h#n20,
which is then also nicely tested using compile-time asserts in
https://code.qt.io/cgit/qt/qtbase.git/tree/tests/auto/corelib/kernel/qjnitypes/tst_qjnitypes.cpp
- so I very much sympathise with the idea. For type authors, this can be a
very good unit-testing tool; but perhaps not so much for code using those types.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Future of constexpr in Qt?
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
Re: [Interest] Future of constexpr in Qt?
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? These are so common in our codebase that without them, only a relatively few functions can ever be made constexpr. 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. Kind regards Robert -Original Message- From: Volker Hilsheimer Sent: Thursday, 21 November 2024 17:42 To: Schimkowitsch Robert Cc: interest@qt-project.org Subject: Re: [Interest] Future of constexpr in Qt? CAUTION: External email. Do not click on links or open attachments unless you know the sender and that the content is safe. > On 21 Nov 2024, at 10:55, Schimkowitsch Robert > wrote: > > I’d like to use constexpr more in the future in order to catch UB in > compile-time tests of functions. > Qt has a little constexpr sprinkled here and there, but not a lot. Does > anyone know if there are plans to expand Qt in this direction? > Kind regards > Robert Hi Robert, It’s generally not an item on the roadmap to make constexpr everything that can be. But when we touch code with expressions that could be constexpr, then we might make that change as a drive-by, if the code would otherwise benefit from it. If there’s any part of Qt where you’d see significant value from making things constexpr, then you’re welcome to push things for review. Cheers, Volker This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. ANDRITZ HYDRO GmbH Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation Firmensitz/ Registered seat: Wien Firmenbuchgericht/ Court of registry: Handelsgericht Wien Firmenbuchnummer/ Company registration: FN 61833 g DVR: 0605077 UID-Nr.: ATU14756806 Thank You ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Future of constexpr in Qt?
> On 21 Nov 2024, at 10:55, Schimkowitsch Robert > wrote: > > I’d like to use constexpr more in the future in order to catch UB in > compile-time tests of functions. > Qt has a little constexpr sprinkled here and there, but not a lot. Does > anyone know if there are plans to expand Qt in this direction? > Kind regards > Robert Hi Robert, It’s generally not an item on the roadmap to make constexpr everything that can be. But when we touch code with expressions that could be constexpr, then we might make that change as a drive-by, if the code would otherwise benefit from it. If there’s any part of Qt where you’d see significant value from making things constexpr, then you’re welcome to push things for review. Cheers, Volker ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Future of constexpr in Qt?
I’d like to use constexpr more in the future in order to catch UB in compile-time tests of functions. Qt has a little constexpr sprinkled here and there, but not a lot. Does anyone know if there are plans to expand Qt in this direction? Kind regards Robert This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. ANDRITZ HYDRO GmbH Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation Firmensitz/ Registered seat: Wien Firmenbuchgericht/ Court of registry: Handelsgericht Wien Firmenbuchnummer/ Company registration: FN 61833 g DVR: 0605077 UID-Nr.: ATU14756806 Thank You ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
