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
