Странное использование `?:` в коде `typeid`

Я думаю это оптимизация! Малоизвестная и редко (можно сказать «никогда») используемая особенность typeid заключается в том, что нулевое разыменование аргумента typeid вызывает исключение вместо обычного UB.

Какой? Ты серьезно? Ты пьян?

Конечно. да. Нет.

int *p = 0;
*p; // UB
typeid (*p); // throws

Да, это уродливо, даже по стандарту уродства языка С++.

OTOH, это не работает нигде внутри аргумента typeid, поэтому добавление любого беспорядка отменит эту «функцию»:

int *p = 0;
typeid(1 ? *p : *p); // UB
typeid(identity(*p)); // UB

Для протокола: в этом сообщении я не утверждаю, что автоматическая проверка компилятором того, что указатель не равен нулю, перед разыменованием обязательно является безумием. Я только говорю, что делать эту проверку, когда разыменование является непосредственным аргументом typeid, а не где-либо еще, совершенно безумно. (Возможно, это была шутка, вставленная в какой-то черновик, и так и не удаленная.)

Для справки: я не утверждаю в предыдущем «Для справки», что для компилятора имеет смысл вставлять автоматические проверки того, что указатель не является нулевым, и генерировать исключение (как в Java) при разыменовании нулевого значения. : вообще генерировать исключение при нулевом разыменовании абсурдно. Это ошибка программирования, поэтому исключение не поможет. Требуется отказ утверждения.

Единственный эффект, который я вижу, заключается в том, что 1 ? X : X дает вам X в качестве rvalue вместо обычного X, которое было бы lvalue. Это может иметь значение для typeid() для таких вещей, как массивы (распадающиеся до указателей), но я не думаю, что это будет иметь значение, если известно, что Derived является классом. Возможно, он был скопирован откуда-то, где rvalue-ness имел значение? Это поддержало бы комментарий о «культовом программировании грузов».

Что касается комментария ниже, я сделал тест и, конечно же, typeid(array) == typeid(1 ? array : array), так что в некотором смысле я ошибаюсь, но мое непонимание все еще может соответствовать недоразумению, которое привело к исходному коду!

Это поведение описано в [expr.typeid]/2 (N3936):

Когда typeid применяется к выражению glvalue, тип которого является типом полиморфного класса, результат ссылается на объект std::type_info, представляющий тип наиболее производного объекта (то есть динамического типа), на который ссылается glvalue. Если выражение glvalue получено путем применения унарного оператора * к указателю, а указатель является нулевым значением указателя, выражение typeid создает исключение типа, которое соответствует обработчику исключения типа std::bad_typeid.

Выражение 1 ? *p : *p всегда является lvalue. Это связано с тем, что *p является lvalue, а [expr.cond]/4 говорит, что если второй и третий операнд тернарного оператора имеют один и тот же тип и категорию значения, то результат операции также имеет этот тип и категорию значения.

Следовательно, 1 ? *m_basePtr : *m_basePtr — это lvalue с типом Base. Поскольку Base имеет виртуальный деструктор, это тип полиморфного класса.

Следовательно, этот код действительно является примером «Когда typeid применяется к выражению glvalue, тип которого является типом полиморфного класса».

Теперь мы можем прочитать остальную часть приведенной выше цитаты. Выражение glvalue было не "получено путем применения унарного оператора * к указателю" — оно было получено с помощью тернарного оператора. Поэтому стандарт не требует создания исключения, если m_basePtr имеет значение null.

Поведение в случае, когда m_basePtr равно null, будет регулироваться более общими правилами разыменования нулевого указателя (которые на самом деле немного туманны в C++, но для практических целей мы предположим, что здесь это приводит к неопределенному поведению).

Наконец: зачем кому-то это писать? Я думаю, что ответ любопытного парня пока является наиболее правдоподобным предположением: с этой конструкцией компилятору не нужно вставлять проверку нулевого указателя и код для генерации исключения, поэтому это микрооптимизация.

Предположительно, программист либо достаточно доволен тем, что это никогда не будет вызываться с нулевым указателем, либо счастлив полагаться на конкретную реализацию обработки разыменования нулевого указателя.

Я подозреваю, что какой-то компилятор был, для простого случая

typeid(*m_basePtr)

возвращает typeid(Base) всегда, независимо от типа среды выполнения. Но превращение его в выражение/temporary/rvalue заставило компилятор выдать RTTI.

Вопрос в том, какой компилятор, когда и т. д. Я думаю, что у GCC были проблемы с typeid на раннем этапе, но это смутное воспоминание.