On Tuesday 27 August 2024 10:29:05 GMT-7 Ville Voutilainen wrote: > On Tue, 27 Aug 2024 at 17:15, Thiago Macieira <thiago.macie...@intel.com> wrote: > > The point is that this putative mistake has no consequences, today. It > > remains to be seen whether it will with contracts, when those come. When > > contracts come, if those noexcept are a problem, then both libc++ and > > libstdc++ will deploy a solution, which should suffice for us too. Until > > then, I don't see a reason to deprive ourselves of any potential benefits > > that the noexcept might bring. > > What benefits?
TBH, it's actually very little. But little is not zero. For the direct use of simple and not-so-simple inline functions, probably none. The compiler is good at seeing no exceptions are actually thrown. It starts to get interesting for code that checks on the noexceptness of the content it's calling and use different algorithms. There aren't a lot of those outside of container copy, but they do exist. There's the case of the complex sequence of inline functions where the compiler does not inline them all, in which case it may also not propagate the fact that no exceptions are actually thrown. In that case, the compiler will need to generate code to deal with exceptions that aren't there, which may hinder some optimisations. This is of course a QoI problem and I don't know what the state-of-the-art here is. Then there are the out-of-line functions. But here I think we have a precedent in the library coding rule that we don't use Q_ASSERT to check on user input (preconditions). We may produce a qWarning, but usually just return or set an error condition. Plus, for most out-of-line functions either can't be noexcept anyway because they allocate memory somehow. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
