On 27.08.24 01:33, Ville Voutilainen wrote:
> On Mon, 26 Aug 2024 at 20:41, Marc Mutz via Development
> wrote:
>> What is unacceptable in (1) (doing nothing) is not even _informing_
>> users about what we found¹, so _they_ can decide for themselves what to do.
>>
>> ¹ neither at compile-time, nor
On Mon, 26 Aug 2024 at 20:41, Marc Mutz via Development
wrote:
> What is unacceptable in (1) (doing nothing) is not even _informing_
> users about what we found¹, so _they_ can decide for themselves what to do.
>
> ¹ neither at compile-time, nor runtime, nor coding time (static checker)
>nor a
On Monday 26 August 2024 12:22:09 GMT-7 Giuseppe D'Angelo via Development
wrote:
> There's a perfect place for such warnings, and that's tooling like Clazy
> / Clang-tidy (where you could also extend this to cover way more than
> QVariant -- any Qt / std container, algorithm, and so on).
Then l
Il 26/08/24 19:49, Thiago Macieira ha scritto:
A runtime warning is unacceptable because it adds to the cost of the 99.99%
who don't have a throwing destructor.
A compile-time warning implies having a way to disable it with "I know that,
just ignore it" which is maintenance for us. My problem wi
On Monday 26 August 2024 10:39:56 GMT-7 Marc Mutz via Development wrote:
> On 26.08.24 08:43, Ville Voutilainen wrote:
> >> 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 edu
On 26.08.24 08:43, Ville Voutilainen wrote:
>> 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 ~QVa
On 26.08.24 11:08, Giuseppe D'Angelo via Development wrote:
> Il 26/08/24 07:24, Marc Mutz via Development ha scritto:
>> 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 educa
Il 26/08/24 07:24, Marc Mutz via Development ha scritto:
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 ~
On Mon, 26 Aug 2024 at 08:26, Marc Mutz via Development
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_
(sorry for the late entrance, was OOO the last two weeks)
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_destructib
> On 9 Aug 2024, at 17:52, Thiago Macieira wrote:
>
> On Friday 9 August 2024 01:46:02 GMT-7 Fabian Kosmale via Development wrote:
>> 1. Don't do anything; that's the behavior we have since at least Qt 5.
>> If the dtor doesn't actually throw, everything is fine; if it does
>> throw, we're callin
On Friday 9 August 2024 01:46:02 GMT-7 Fabian Kosmale via Development wrote:
> 1. Don't do anything; that's the behavior we have since at least Qt 5.
> If the dtor doesn't actually throw, everything is fine; if it does
> throw, we're calling std::terminate. Might lead to unexpected results,
> but d
Hi,
Qt's container classes (at least those listed in
https://doc.qt.io/qt-6/containers.html + QCache) reject types with
throwing destructorss via static_assert[1].
There is however one "container" which doesn't reject such types:
QVariant. Even though it's own destructor is noexcept, it does
13 matches
Mail list logo
