[Development] QVariant and types with throwing dtors
Ville Voutilainen
ville.voutilainen at gmail.com
Mon Aug 26 08:43:49 CEST 2024
On Mon, 26 Aug 2024 at 08:26, Marc Mutz via Development
<development at qt-project.org> wrote:
> My vote goes to (3). (2) is a good intermediate step (e.g. for Qt 6,
> with Qt 7 converting to static_assert()). Remember that ctors are
> implicitly noexcept in C++, so you need to do actual work to make a type
> that's not nothrow_destructible. In Qt, incl. 3rd-party monster
> chromium, we have _two_ such types, QChildProcess and
> QScopedPropertyUpdateGroup. QtC has another two, in sqlite:
> ~AbstractThrowingSessionTransaction and ~AbstractThrowingTransaction.
>
> So, by an educated guesstimation, this won't be an issue, and possibly
> catch mistakes, like when using a 3rd-party library type in QVariant.
>
> The other option (4) is to make it supported: have a
> QVariant::destroy<T>() function that's conditionally noexcept, so users
> can destroy the payload in a controlled environment instead of running
> into std::terminate() in ~QVariant() (throwing from a noexcept function
> will _not_ unroll the stack, so you might not even get logging that you
> expected).
>
> IMHO, (1) is not an acceptable option. Us C++ professionals having identified
> this problem after years of it lying dormant, it behooves us, at the
> very least, to educate our users about this, e.g. by adding docs, and
> maybe a qWarning() in ~QVariant(), if we don't do (2).
If it's not an issue, why is (1) unacceptable?
More information about the Development
mailing list