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 not included. This is very easy to > implement with a static checker. > > We could be more complex, with "Q_ASSERT that check preconditions imply > noexcept(false) but Q_ASSERT that verify the state of the internal invariant > against corruption don't". This would not be easy to implement with a > static checker.
I propose we follow the Standard Library implementors' example of std::vector::operator[] libstdc++ does have an assertion there: const_reference operator[](size_type __n) const _GLIBCXX_NOEXCEPT { __glibcxx_requires_subscript(__n); return *(this->_M_impl._M_start + __n); } So does libc++: vector<_Tp, _Allocator>::operator[](size_type __n) _NOEXCEPT { _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(__n < size(), "vector[] index out of bounds"); return this->__begin_[__n]; } Let's call this Pragmatic Lakos Rule. -- 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