On Tue, 27 Aug 2024 at 05:21, Thiago Macieira wrote:
>
> On Monday 26 August 2024 17:18:22 GMT-7 Ville Voutilainen wrote:
> > So eventually such libraries
> > need to
> > be fixed so that they ship configurations and builds where such
> > functions can be compiled as non-noexcept with contract che
On Tue, 27 Aug 2024 at 05:23, Thiago Macieira wrote:
>
> On Monday 26 August 2024 17:09:54 GMT-7 Ville Voutilainen wrote:
> > I would think the callee takes over the responsibility of destroying
> > the parameters when they have all been initialized
> > (so that you actually end up in the callee,
On Tue, 27 Aug 2024 at 05:18, Thiago Macieira wrote:
>
> On Monday 26 August 2024 15:35:11 GMT-7 Ville Voutilainen wrote:
> > > a) turning precondition checks into runtime validations
> > > b) using exceptions for the runtime validation
> > > c) violating the precondition that caused the proble
On 26.08.24 22:12, Thiago Macieira wrote:
> On Monday 26 August 2024 12:55:04 GMT-7 Marc Mutz via Development wrote:
>> I don't see a proposal for an alternative rule in the above. Please
>> provide a) a new rule and b) rationale for it. Bonus points for being
>> implementable in a static checker l
On Monday 26 August 2024 22:16:46 GMT-7 Marc Mutz via Development wrote:
> This is an iterator API, and that lhs.item.d == rhs.item.d is a
> precondition of the equality operator, so outside of our control. As I
> mentioned on Gerrit, we can control the width of the contract we choose
> to provide,
Your two examples are quite different, though:
On 26.08.24 22:28, Thiago Macieira wrote:
> On Monday 26 August 2024 12:59:54 GMT-7 Marc Mutz via Development wrote:
>> Part of why I'm sympathetic to the assertions throw mantra is that I
>> used it very successfully in Kleopatra way back when. We co
Hi all,
String freeze for Qt 6.8 is in effect now.
br,
Jani
From: Jani Heikkinen
Sent: keskiviikko 21. elokuuta 2024 8.05
To: localizat...@qt-project.org; development@qt-project.org;
releas...@qt-project.org
Subject: HEADS UP : Qt 6.8 soft string freeze
Hi all,
First beta releases from
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 Monday 26 August 2024 17:09:54 GMT-7 Ville Voutilainen wrote:
> I would think the callee takes over the responsibility of destroying
> the parameters when they have all been initialized
> (so that you actually end up in the callee, duh), and before that
> point the caller has to do it for cases
On Monday 26 August 2024 17:18:22 GMT-7 Ville Voutilainen wrote:
> So eventually such libraries
> need to
> be fixed so that they ship configurations and builds where such
> functions can be compiled as non-noexcept with contract checks turned
> on, so that
> throwing violation handlers can be used
On Monday 26 August 2024 15:35:11 GMT-7 Ville Voutilainen wrote:
> > a) turning precondition checks into runtime validations
> > b) using exceptions for the runtime validation
> > c) violating the precondition that caused the problem.
>
> Right. Preconditions are as-if in the function body. Bot
On Tue, 27 Aug 2024 at 02:24, Thiago Macieira wrote:
>
> On Monday 26 August 2024 13:12:55 GMT-7 Thiago Macieira wrote:
> > "Q_ASSERT don't affect noexceptness"
> >
> > Or
> >
> > "noexcept(false) if you call other, noexcept(false) functions from your
> > code", which includes all the pthread canc
On Tue, 27 Aug 2024 at 02:13, Thiago Macieira wrote:
>
> On Monday 26 August 2024 15:25:40 GMT-7 Ville Voutilainen wrote:
> > There's a difference between a function being noexcept and calls to a
> > function not throwing exceptions. Parameter initialization
> > can throw without terminating, for
On Tue, 27 Aug 2024 at 02:10, Thiago Macieira wrote:
> > A contract violation turned into an exception cannot escape out of a
> > noexcept function. So it won't bubble up.
>
> I think that's a mistake, but since I don't use exceptions, I also don't care.
It isn't. It avoids functions being condit
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 13:12:55 GMT-7 Thiago Macieira wrote:
> "Q_ASSERT don't affect noexceptness"
>
> Or
>
> "noexcept(false) if you call other, noexcept(false) functions from your
> code", which includes all the pthread cancellation points in glibc. Since
> qt_assert is noexcept, Q_ASSERT is
On Monday 26 August 2024 13:12:55 GMT-7 Thiago Macieira wrote:
> "Q_ASSERT don't affect noexceptness"
>
> Or
>
> "noexcept(false) if you call other, noexcept(false) functions from your
> code", which includes all the pthread cancellation points in glibc. Since
> qt_assert is noexcept, Q_ASSERT is
On Monday 26 August 2024 15:25:40 GMT-7 Ville Voutilainen wrote:
> There's a difference between a function being noexcept and calls to a
> function not throwing exceptions. Parameter initialization
> can throw without terminating, for a call of a noexcept function.
Side question: what happens to p
On Monday 26 August 2024 15:47:10 GMT-7 Ville Voutilainen wrote:
> On Mon, 26 Aug 2024 at 22:29, Giuseppe D'Angelo via Development
>
> wrote:
> > Il 26/08/24 19:56, Thiago Macieira ha scritto:
> > > I'd like to request Qt code not obey that rule. In my opinion, it's a
> > > defect in the contract
On Mon, 26 Aug 2024 at 22:29, Giuseppe D'Angelo via Development
wrote:
>
> Il 26/08/24 19:56, Thiago Macieira ha scritto:
> > I'd like to request Qt code not obey that rule. In my opinion, it's a defect
> > in the contract implementation rather than on Qt code. The*pre* condition
> > indicates so
On Mon, 26 Aug 2024 at 22:51, Thiago Macieira wrote:
>
> On Monday 26 August 2024 12:27:47 GMT-7 Giuseppe D'Angelo via Development
> wrote:
> > Il 26/08/24 19:56, Thiago Macieira ha scritto:
> >
> > > I'd like to request Qt code not obey that rule. In my opinion, it's a
> > > defect
> in the cont
On Mon, 26 Aug 2024 at 23:25, Fabian Kosmale via Development
wrote:
>
> Hi,
>
> I'm somewhat sympathetic to Thiago's proposal, but with different reasoning.
> The Lakos rule is indeed motivated by contracts, and by the fact that the
> standard is extremely reluctant to do breaking changes.
> Now
On Monday 26 August 2024 13:12:55 GMT-7 Thiago Macieira wrote:
> "Q_ASSERT don't affect noexceptness"
>
> Or
>
> "noexcept(false) if you call other, noexcept(false) functions from your
> code", which includes all the pthread cancellation points in glibc. Since
> qt_assert is noexcept, Q_ASSERT is
On Monday 26 August 2024 12:59:54 GMT-7 Marc Mutz via Development wrote:
> Part of why I'm sympathetic to the assertions throw mantra is that I
> used it very successfully in Kleopatra way back when. We could easily
> take the exception's what() and report back over the UI server channel
> that an
Hi,
I'm somewhat sympathetic to Thiago's proposal, but with different reasoning.
The Lakos rule is indeed motivated by contracts, and by the fact that the
standard is extremely reluctant to do breaking changes.
Now, contracts will be in no earlier than C++23 even in the best case (and
personall
On Monday 26 August 2024 12:55:04 GMT-7 Marc Mutz via Development wrote:
> I don't see a proposal for an alternative rule in the above. Please
> provide a) a new rule and b) rationale for it. Bonus points for being
> implementable in a static checker like Clazy or Axivion.
"Q_ASSERT don't affect n
On 26.08.24 21:49, Thiago Macieira wrote:
> In particular, I don't see why (b) should be used at all. A precondition
> violation implies that the state was unexpected at that point. How is an
> exception going to help recovering? That sounds like an exception that would
> bubble up all the way back
On 26.08.24 19:56, Thiago Macieira wrote:
> The Lakos Rule says that methods that only methods with wide contracts should
> be noexcept. That is, if your method has a precondition, it should not be
> noexcept.
>
> This is apparently predicated on the fact that the preconditions will be
> implement
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
On Monday 26 August 2024 12:27:47 GMT-7 Giuseppe D'Angelo via Development
wrote:
> Il 26/08/24 19:56, Thiago Macieira ha scritto:
>
> > I'd like to request Qt code not obey that rule. In my opinion, it's a
> > defect
in the contract implementation rather than on Qt code. The*pre*
> > condition
Il 26/08/24 19:56, Thiago Macieira ha scritto:
I'd like to request Qt code not obey that rule. In my opinion, it's a defect
in the contract implementation rather than on Qt code. The*pre* condition
indicates something that must be true before the method is called and
therefore the method's own n
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
The Lakos Rule says that methods that only methods with wide contracts should
be noexcept. That is, if your method has a precondition, it should not be
noexcept.
This is apparently predicated on the fact that the preconditions will be
implementable as C++ contracts some time in the future and t
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
Hi all,
There will be a maintenance break on the codereview.qt-project.org on Monday
2-Sep 7:00 am – 9:00 am CEST.
The Gerrit version will be upgraded to 3.8.8.
--Jukka Jokiniva, Gerrit Admin
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/devel
We will perform our monthly maintenance break on the CI on next Monday 2.9.2024
starting at 04:00 UTC / 07:00 Finnish time. We will update operating systems
and firmware in our infra.
Estimate for the downtime is 7 hours, depending on the speed of the upgrades.
--
Development mailing list
Dev
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 09.12.23 18:38, Thiago Macieira wrote:
> On Friday, 8 December 2023 18:51:19 PST Marc Mutz via Development wrote:
>> I think we need to mandate that if you want qint128 support, then you
>> must compile with gnu++NN, which is actually the default on both GCC and
>> Clang. We seem to switch that
40 matches
Mail list logo
