Динамическая путаница

Я отказываюсь от этого...

$5.2.7/2- "Если T - тип указателя, v должно быть rзначением указателя на полный тип класса, и результат r значение типа T. Если T является ссылочный тип, v должен быть lvalue полного типа класса, и результатом является lзначение типа обозначаемый Т.

В соответствии с вышесказанным, следующий код должен быть хорошо сформирован.

struct A{};
struct B : A{};

int main(){
   B b;
   A a, &ar1 = b;

   B& rb1 = dynamic_cast<B&>(ar1);  // Does not $5.2.7/2 apply here?
   B& rb2 = dynamic_cast<B&>(a);    // and also here?
}

Но это не так. Все компиляторы жалуются на то, что операнд для dynamic_cast не является полиморфным в соответствии с

$5.2.7/6- В противном случае v будет указатель на или значение l полиморфный тип (10.3).

Итак, мой вопрос в том, что означает $5.2.7/2? Почему здесь стоит $5.2.7/6?

Ответ 1

"В противном случае" в этом случае означает "если не применяются условия в 5.2.7/5".

Вы можете сказать это, потому что /2 устанавливает требование к программе относительно операнда dynamic_cast (обратите внимание, что язык "должен" "v должен быть lvalue" по сравнению с "is" языком "результатом является lvalue" ). Как и в других местах в стандарте, выражение требования не обязательно означает, что это единственное требование. В других положениях могут указываться дополнительные требования. В этом случае /6 указывает дополнительное требование, которое применяется только в определенных случаях, в зависимости от T и статического типа v.

/3,/4,/5 сообщают вам о значении результата, и они полностью согласуются с требованием в /2. Ни один из них не начинается с "Иначе". Поэтому для меня довольно очевидно, что они не образуют цепочку "else if", начинающуюся с /2.

Некоторые скобки или что-то могут сделать это более ясным (то есть, что "в противном случае" в /6 относится к "if" в /5, а не к "if" в /2,/3 или/4). Но это просто не стиль дома.

Помимо всего прочего, "в противном случае" в /5 логически не может осмысленно применяться к условиям в /2./1 говорит, что T должен быть "указателем или ссылкой на полный тип класса, или cv void*". /2 охватывает два случая - типы указателей и ссылочные типы. Это все. Нет "в противном случае" для /2 (если не сказать "иначе, соответствующий компилятор должен выдать диагностику", но это неявно)

Ответ 2

Ну, все требования в 5.2.7 должны соблюдаться вместе. Вы не можете просто остановиться после 5.2.7/2 и начать писать код, который предположительно удовлетворяет всем "до 5.2.7/2". Все 5.2.7 определяют спецификацию dynamic_cast.

Полиморфное требование выделяется, поскольку оно является условным. Когда вы используете dynamic_cast для upcasts, полиморфное требование не применяется (фактически, dynamic_cast эквивалентно static_cast в upcasts). Полиморфное требование применяется только тогда, когда вы используете dynamic_cast для downcasts или crosscasts.

Спецификация dynamic_cast организована последовательно, а это означает, что сначала она заботится о более простых случаях, а затем переходит к более сложным приложениям. Вы должны читать его шаг за шагом, пока он не покрывает вашу конкретную ситуацию. Все, что вы читаете по этому пути, применяется кумулятивно. И "в противном случае" означает: "если мы еще не рассмотрели ваше дело, продолжайте читать".

Ответ 3

Чтобы сделать downcast, как в вашем примере, Struct A должен быть полиморфным и иметь RTTI. Здесь скорректированная версия, которая работает, до точки:

struct A{virtual void f(){}};
struct B : A{};

int main(){
   B b;
   A a, &ar1 = b;

   B& rb1 = dynamic_cast<B&>(ar1);  // Does not $5.2.7/2 apply here?
   //B& rb2 = dynamic_cast<B&>(a);    // and also here?
}

Добавив виртуальное, делая его полиморфным, RTTI включен для класса, позволяя downcasts.

Обратите внимание, что ваш второй пример не может работать - поскольку вы накладываете pod (a) на ссылку на pod - это недопустимо.

Update:

Ваш код не разрешен в соответствии с 5.2.7.5 и не разрешен в соответствии с 5.2.7.6. Моя настройка позволяет работать в соответствии с 5.2.7.6