Отсутствует обязательное включение неопределенного поведения? - PullRequest
Новая
       17

Отсутствует обязательное включение неопределенного поведения?

5 голосов
/ 20 апреля 2020

Когда я писал ответ на Как можно использовать pow без включения библиотеки cmath Я боюсь доказать, что пропуск включения необходимого заголовка на самом деле неопределенное поведение, но так как я не нашел Любое согласие с этим фактом мне нравится навязывать формальный вопрос:

Отсутствует обязательный заголовок, т.е. 

#include <iostream>

int main()
{
    std::cout << std::pow(10, 2);
}
  1. Плохо сформированный ([defns.ill.formed]) код ?
  2. Вызов неопределенного поведения ([defns.undefined])?
  3. Если это не 1 и 2, это неуказанное поведение [defns.unspecified] или поведение, определяемое реализацией [defns.impl .defined]?
  4. Если нет 1. То есть, если этот код правильно сформирован, это не противоречит [using.headers] и [intro.compliance] "принимать и правильно выполнять правильно сформированную программу" ?

Как и в моем ответе Я склонен утвердить оба вопроса, но [using.headers] очень сбивает с толку из-за разницы между неопределенным поведением и плохо сформированным, нет диагностики c сообщение требуется * 1 021 *. Поскольку [defns.well.formed] подразумевает, что программа, созданная для ODR, правильно сформирована, и существует спецификация того, что, например, iostream не должен определять pow, можно утверждать, что это все еще неопределенное поведение ([defns .неопределенные]). Я не хочу полагаться только на свои стандартные навыки устного перевода для окончательного ответа на такой важный вопрос. Обратите внимание, что принятый, т.е. единственный другой ответ, не отвечает, если код UB, и не задает вопрос.

1 Ответ

2 голосов
/ 21 апреля 2020

Это не определено , является ли эта программа правильно сформированной или плохо сформированной (с необходимым диагнозом c, потому что поиск имени не находит pow). Возможности возникают из утверждения, что один заголовок C ++ может включать в себя другой , который предоставляет разрешение реализации, чтобы дать этой программе одну из двух возможных интерпретаций.

Несколько аналогичные правила ( например , что шаблон должен иметь хотя бы одну допустимую потенциальную специализацию) описаны как 1013 * как вывод программы из строя, диагностика не требуется c, но в этой ситуации эта свобода не распространяется на реализацию (что, возможно, предпочтительнее). Тем не менее, реализация позволяет обрабатывать неправильно сформированную программу произвольным образом 1017 *, если она выдает хотя бы одно сообщение о диагностике c, поэтому это не является абсолютно необоснованным для Сгруппируйте эту ситуацию с истинно неопределенным поведением, хотя на практике симптомы различаются.

...