Проверяется ли «постоянная функция-член» во время компиляции или во время выполнения?

#c

#c

Вопрос:

Мне интересно, когда происходит проверка const функции-члена? Я предполагаю, что это происходит во время компиляции, но не могу быть уверен. Кто-нибудь знает?

Ответ №1:

Это происходит во время компиляции. В C почти вся проверка типов выполняется во время компиляции. Единственным исключением из этого является использование dynamic_cast .

Итак, ваша const функция-член проверяется во время компиляции.

Комментарии:

1. catch есть еще одно «исключение» (ха-ха), когда типы проверяются во время выполнения. Генерируемое исключение (тип которого является статическим типом выражения throw) сравнивается с любыми предложениями catch, находящимися в стеке вызовов в данный момент. В общем случае это не может быть известно до времени выполнения, например, вызвать что-либо через указатель на функцию, который вызывает через другой указатель на функцию в вызывающий код, и эта средняя вещь в стеке может быть любой функцией в программе с правильной подписью. Не поддается статическому анализу.

2. В некотором смысле виртуальные методы можно рассматривать как проверку типа во время выполнения (особенно вызовы указателя на элемент виртуальных функций с виртуальными базовыми классами).

3. О’Мальчик, педантичная полиция добралась сюда первой.

Ответ №2:

const Функция-член проверяется во время компиляции.

Ответ №3:

const наличие функций-членов влияет на тип this указателя. Безопасность типов проверяется во время компиляции (если не обходится с помощью приведения, большинство приведений обходят проверки безопасности, dynamic_cast добавляет проверку во время выполнения).

Однако на большинстве архитектур const ness — это не просто проверка типа, а принудительная с помощью модуля защиты памяти. Это происходит во время выполнения и НЕ обходится const_cast (или приведением в стиле C).

Комментарии:

1. Мне трудно в это поверить; большинство объектов const не являются постоянными все время и, следовательно, должны находиться в доступной для записи памяти.

2. @Neil: Я думаю, вы имеете в виду постоянный указатель на неконстантный объект? объекты const всегда являются const, const_cast не могут быть удалены const , которые были применены во время построения.

3. const обычно MMU не применяется для типов со сложными конструкторами, то есть для тех ctors, которые не могут быть сведены к операциям времени компиляции.

4. @MSalters: Мы смотрим на две разные стороны одного и того же. Проверки MPU не гарантированы, но они разрешены. То, что скомпилированный код не означает, что он не завершится сбоем во время выполнения из-за нарушения доступа, обнаруженного MPU.

5. @Бен Войт: очевидно, на наличие неправильного кода (с неопределенным поведением). Но если скомпилирован код, соответствующий стандартам, компилятор может не использовать инструкции, которые привели бы к сбою проверки MPU. Конструкторы действительно выполняются для const объектов и им разрешено изменять элементы ( this указатель еще не const установлен), так что это особый случай кода со стандартами-жалобами, где MPU должен разрешить операцию.