On 31.08.24 20:01, Ville Voutilainen wrote:
> On Fri, 30 Aug 2024 at 19:21, Thiago Macieira <thiago.macie...@intel.com>
> wrote:
>> For the non-simple cases, we may need two macros, one that expands to:
>>
>> noexcept(noexcept(std::string_view{"", 1}))
>>
>> and the other that expands to the pre() specifier.
>
> Right. Maybe
>
> void f(int x) Q_NARROW_CONTRACT_NOEXCEPT Q_PRE(x >= 0) ;
>
> and then, if contracts are enabled, that noexcept expands to nothing,
> and if contracts are disabled,
> the pre expands to nothing and that noexcept expands to a noexcept.
I'm really doubting the wisdom of adding another dimension of build to
Qt. We already have release/debug, and Q_NARROW_CONTRACT_NOEXCEPT would
mean an orthogonal build mode. So on Windows we'd need four builds per
compiler. Assuming, as I do, that that feature will be in high demand by
users once available. Nothing we haven't done before (Qt 3 had
debug/release × multi/single-threaded), but just like Qt 4 ditched the
non-MT build mode, I expect we'd be ditching the
non-contracts-checking-supporting (noexcept enabled) build mode ere
long, because it turns out to be too much of burden to carry around with
(presumably) too little a benefit.
As is well-known, not all users of Qt build Qt from scratch. Think Linux
distributions. The Lakos Rule ensures that a single build can be used
for both checked and unchecked contract mode, with the control lying in
the hands of the owner of main(), where we seem to agree it belongs.
I also question the notion of "we don't do exceptions in Qt" popping up
between the lines in this thread. We _do_ support them in QtCore and
QtTest, and it's Core you're proposing to plaster with noexcept.
Exception-unsafe code is also prone to Static Analyzer complaints, and,
once again, legislators are working on forcing software companies to do
more for security, not less (and one of the ways TQtC has decided to
take this is to listen to SA tools more (Axivion, but Qt is also covered
by Clang-SA and Coverity)). I believe one goal of contracts is to make
C++ an (optionally) checked language.
We need _more_ exception (= resource) safety and not less. Exception
safety doesn't mean QT_TRY and QT_CATCH, but, in 95% of cases, RAII, and
RAII helps also against laissez-faire coding practices (see
https://codereview.qt-project.org/c/qt/qtbase/+/551854 for a recent
example) that have nothing to do with exceptions. Build-conditional
noexcept and ignoring exception safety is heading into the opposite
direction of where I, at least, see that Qt needs to go. Besides, libc++
recently ditched their build-conditional noexcept approach, AFAIK. We
needn't make mistakes others have already done for us.
Thanks,
Marc
--
Marc Mutz <marc.m...@qt.io> (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
