Какие значения перечисления являются неопределенным поведением в С++ 14 и почему?

Clang помечает использование static_cast для значения, выходящего за пределы допустимого диапазона. Поведение не определено, если значение интеграла не входит в диапазон перечисления.

C++ standard 5.2.9 Static cast [expr.static.cast] paragraph 7

A value of integral or enumeration type can be explicitly converted to an enumeration type. The value is unchanged if the original value is within the range of the enumeration values (7.2). Otherwise, the resulting enumeration value is unspecified / undefined (since C++17).

Обратите внимание на формулировку сноски 100: «[Этот набор значений] не исключает [вещей]». Это не подтверждение того, что «вещи» действительны; это просто подчеркивает, что эта секция не объявляет материал недействительным. На самом деле это нейтральное утверждение, которое должно напомнить ошибка исключенного третьего. Что касается этого раздела, значения вне значений перечисления не одобряются и не отклоняются. Этот раздел определяет, какие значения находятся за пределами значений перечисления, но решение о допустимости использования таких значений оставлено на усмотрение других разделов (например, expr.pre).

Вы можете рассматривать эту сноску как предупреждение тем, кто пишет компиляторы: не предполагайте! Выражение типа перечисления не обязательно должно иметь значение в наборе значений перечисления. Такой случай должен быть правильно скомпилирован, если другой раздел не классифицирует этот случай как неопределенное поведение.

Чтобы лучше понять, на что именно жалуется clang, попробуйте следующий код:

enum A {B = 3, C = 7};

int main() {
  // Set a variable of type A to a value outside A's set of values.
  A d = static_cast<A>(8);

  // Try to evaluate an expression of type A with this too-big value.
  if ( !static_cast<bool>(static_cast<A>(8)) )
    return 2;

  // Try again, but this time load the value from d.
  if ( !static_cast<bool>(d) ) // Sanitizer flags only this
    return 1;

  return 0;
}

Дезинфицирующее средство не жалуется на принудительное присвоение значения 8 переменной типа A. Он не жалуется на вычисление выражения типа A, которое имеет значение 8 (первый if). Тем не менее, он жалуется, когда значение 8 исходит (является загружен из) переменной типа A.

Я не совсем знаком с компилятором Clang, так как привык к Visual Studio. В настоящее время я использую Visual Studio 2017. Мне удалось скомпилировать и запустить ваш код с языковым флагом, установленным как на С++ 14, так и на С++ 17 в сборках отладки x86 и x64. Вместо того, чтобы возвращать дополнение в вашем примере:

return d + B;

Я решил вывести их на консоль:

std::cout << (d + B);

и во всех 4 случаях мой компилятор вывел значение 11.

Я не уверен в GCC, так как я не пробовал его с вашим примером, но это заставляет меня поверить, что это проблема, зависящая от компилятора.

Я перешел по вашей ссылке и прочитал раздел 8, на который вы ссылались, но что привлекло мое внимание в этом черновике, так это детали, взятые из других разделов, а именно 7 и 10.

Раздел 7состояния:

For an enumeration whose underlying type is not fixed, the underlying type is an integral type that can represent all the enumerator values defined in the enumeration. If no integral type can represent all the enumerator values, the enumeration is ill-formed. It is implementation-defined which integral type is used as the underlying type except that the underlying type shall not be larger than int unless the value of an enumerator cannot fit in an int or unsigned int. If the enumerator-list is empty, the underlying type is as if the enumeration had a single enumerator with value 0.

Но именно это предложение или пункт привлекли мое внимание:

It is implementation-defined which integral type is used as the underlying type except that the underlying type shall not be larger than int unless the value of an enumerator cannot fit in an int or unsigned int.

Раздел 10состояния:

The value of an enumerator or an object of an unscoped enumeration type is converted to an integer by integral promotion. [ Example:

enum color { red, yellow, green=20, blue };
color col = red;
color* cp = &col;
if (*cp == blue)     // ...

makes color a type describing various colors, and then declares col as an object of that type, and cp as a pointer to an object of that type. The possible values of an object of type color are red, yellow, green, blue; these values can be converted to the integral values 0, 1, 20, and 21. Since enumerations are distinct types, objects of type color can be assigned only values of type color.

color c = 1;        // error: type mismatch, no conversion from int to color
int i = yellow;     // OK: yellow converted to integral value 1, integral promotion

Note that this implicit enum to int conversion is not provided for a scoped enumeration:

enum class Col { red, yellow, green };
int x = Col::red;   // error: no Col to int conversion
Col y = Col::red;
if (y) { }          // error: no Col to bool conversion

— end example ]

Вот эти две строчки привлекли мое внимание:

color c = 1;        // error: type mismatch, no conversion from int to color
int i = yellow;     // OK: yellow converted to integral value 1, integral promotion

Итак, давайте вернемся к вашему примеру:

enum A {B = 3, C = 7};

int main() {
  A d = static_cast<A>(8);
  return d + B;
}

Здесь A — это полный тип, B и C — это перечислители, которые оцениваются как константное выражение целочисленного типа путем продвижения и устанавливаются в значения 3 и 7 соответственно. Это относится к декларации enum A{...};

Теперь внутри main() вы объявляете экземпляр или объект A с именем d, поскольку A является полным типом. Затем вы присваиваете d значение 8, которое является постоянным выражением или константным литералом через механизм static_cast. Я не уверен на 100%, что каждый компилятор выполняет static_cast точно так же или нет; Я не уверен, что это зависит от компилятора.

Таким образом, d — это объект типа A, но, поскольку значение 8 отсутствует в списке перечислений, я считаю, что это подпадает под пункт implementation defined. Затем это должно повысить d до интегрального типа.

Затем в вашем последнем заявлении, где вы возвращаете d+B.

Предположим, что d был повышен до целочисленного типа со значением 8, затем вы добавляете пронумерованное значение B, которое является 3, к 8, и поэтому вы должны получить вывод 11, в котором я во всех 4 моих тестовых случаях на визуальной студии.

Что касается вашего компилятора с Clang, я не могу сказать, но, насколько я могу судить, он не вызывает никаких ошибок или неопределенного поведения, по крайней мере, согласно Visual Studio. Опять же, поскольку этот код, по-видимому, определяется реализацией, я думаю, что это в значительной степени зависит от вашего конкретного компилятора и его версии, а также версии языка, в которой вы его компилируете.

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

-Редактировать-

Я решил запустить это через свой отладчик и поставил точку останова на этой строке:

A d = static_cast<A>(8);

Затем я выполнил эту строку кода и посмотрел значение в отладчике. Здесь, в Visual Studio, d имеет значение 8. Однако под своим типом он указан как A, а не int. Поэтому я не знаю, является ли это продвижением его в int или нет, или это может быть оптимизация компилятора, что-то под капотом, такое как asm, который обрабатывает d как int или unsigned int и т. д.; но Visual Studio позволяет мне присваивать целочисленное значение через static_cast перечисляемому типу. Однако, если я удалю static_cast, он не скомпилируется, заявив, что вы не можете назначить тип int типу A.

Это приводит меня к мысли, что мое первоначальное утверждение выше на самом деле неверно или верно лишь частично. Компилятор не полностью «продвигает» его до целочисленного типа при назначении, поскольку d по-прежнему остается экземпляром A, если только он не делает это под капотом, о чем я не знаю.

Я еще не проверил, чтобы увидеть asm этого кода, чтобы увидеть, какие инструкции по сборке генерируются Visual Studio... поэтому в настоящее время я не могу дать полную оценку на данный момент. Теперь, позже, если у меня будет больше свободного времени; Я могу изучить его, чтобы увидеть, какие строки asm генерируются моим компилятором, чтобы увидеть основные действия, которые выполняет компилятор.