Неопределенное, неопределенное и определяемое реализацией поведение

Ну, это в основном прямая копия-паста из стандартного

3.4.1 1 поведение, определяемое реализацией неопределенное поведение, когда каждая реализация документирует, как выбор сделан

2 ПРИМЕР Пример поведение, определяемое реализацией, распространение бит высокого порядка, когда целое число со знаком сдвигается вправо.

3.4.3 1 undefined поведение, при использовании непереносимого или ошибочного программной конструкции или ошибочной данные, для которых этот Международный Стандарт не предъявляет требований

2 ПРИМЕЧАНИЕ. Возможное поведение undefinedварьируется от игнорирования ситуации полностью с непредсказуемыми результатами, вести себя во время перевода или выполнение программы в документах характер, характерный для окружающей среды (с или без выдача диагностического сообщения), прекращение перевода или исполнения (с выдачей диагностического сообщение).

3 ПРИМЕР Пример undefined поведение - это поведение на целочисленное переполнение.

3.4.4 1 неуказанное поведение использование неопределенного значения или другое поведение где этот международный стандарт предоставляет две или более возможности и не налагает никаких дополнительных требований на который выбирается в любом случае

2 ПРИМЕР Пример неуказанного поведение - это порядок, в котором аргументы функции оцениваются.

Возможно, легкая формулировка может быть проще для понимания, чем строгое определение стандартов.

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

undefined поведение
Вы делаете что-то неправильно. Например, у вас очень большое значение в int, которое не соответствует char. Как вы поместите это значение в char? на самом деле нет пути! Все может случиться, но самым разумным было бы взять первый байт этого int и поместить его в char. Просто неправильно сделать это, чтобы назначить первый байт, но это то, что происходит под капотом.

неуказанное поведение
Какая функция этих двух выполняется сначала?

void fun(int n, int m);

int fun1()
{
  cout << "fun1";
  return 1;
}
int fun2()
{
  cout << "fun2";
  return 2;
}
...
fun(fun1(), fun2()); // which one is executed first?

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

@eSKay Я думаю, что ваш вопрос стоит изменить ответ, чтобы уточнить подробнее:)

для fun(fun1(), fun2()); не является поведение "реализация определена"? Компилятор должен выбрать один или другой курс, в конце концов?

Разница между определяемыми реализацией и неопределенностью заключается в том, что компилятор должен выбрать поведение в первом случае, но это не обязательно во втором случае. Например, реализация должна иметь одно и только одно определение sizeof(int). Таким образом, он не может сказать, что sizeof(int) составляет 4 для некоторой части программы и 8 для других. В отличие от неопределенного поведения, когда компилятор может сказать "ОК", я буду оценивать эти аргументы слева направо, а следующие аргументы функции оцениваются справа налево. Это может произойти в одной и той же программе, поэтому она называется неуказанной. Фактически, С++ можно было бы упростить, если были указаны некоторые из неуказанных поведений. Взгляните здесь на Dr. Stroustrup отвечает за это:

Утверждается, что разница между тем, что можно компилятор этой свободы и требующих "обычных слева направо" оценка "может быть значительным. неубежденным, но бесчисленным компиляторы" там ", используя свободы и некоторых людей страстно защищая эту свободу, изменение было бы трудным и могло бы занять десятилетия, чтобы проникнуть в удаленные углы C и С++ миры. Я разочарован тем, что не все компиляторы предупреждают о ++ я + я ++. Аналогично, порядок оценки аргументов не определено.

ИМО слишком много" вещей" осталось undefined, неопределенный, реализации и т.д. Однако, это легко сказать и даже дать примеры, но трудно исправить. Это следует также отметить, что это не все, что трудно избежать большинства проблемы и производство переносных код.

Из официального документа C Обоснования

Термины неуказанного поведения, поведения undefined и поведения, определенного реализацией, используются для категоризации результата написания программ, свойства которых стандарт не описывает или не может полностью описать. Целью принятия этой категоризации является предоставление определенного разнообразия среди реализаций, которое позволяет качеству реализации быть активной силой на рынке, а также разрешать некоторые популярные расширения, не снимая при этом соответствия стандарту. Приложение F к Стандарту каталогизирует те виды поведения, которые относятся к одной из этих трех категорий.

Неопределенное поведение дает разработчику некоторую широту в переводах программ. Эта широта не распространяется на то, чтобы не перевести программу.

Undefined поведение дает разработчику лицензию не ловить определенные программные ошибки, которые трудно диагностировать. Он также определяет области возможного соответствия языкового расширения: разработчик может расширить язык, предоставив определение официального поведения undefined.

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

Undefined Поведение против неуказанного поведения содержит краткое описание.

Их итоговое резюме:

Подводя итог, неуказанное поведение, как правило, не должно беспокоиться, если ваше программное обеспечение не должно быть портативным. И наоборот, поведение undefined всегда нежелательно и никогда не должно происходят.

Исторически, как поведение, реализованное как реализация, так и поведение Undefined, представляли ситуации, в которых авторы Стандарта ожидали, что люди, записывающие реализации качества, будут использовать суждение, чтобы решить, какие поведенческие гарантии, если таковые имеются, будут полезны для программ в предполагаемом область приложения, работающая по намеченным целям. Потребности кода хеширования высокого класса сильно отличаются от требований низкоуровневого системного кода, и как UB, так и IDB предоставляют гибкость компилятора для удовлетворения этих различных потребностей. Ни одна из категорий не гарантирует, что реализации ведут себя так, что это полезно для какой-либо конкретной цели или даже для каких-либо целей. Однако реализации качества, которые утверждают, что они подходят для определенной цели, должны вести себя таким образом, чтобы соответствовать этой цели, требуется ли это Стандарту или нет.

Единственное различие между поведением, определяемым реализацией и Undefined Behavior, заключается в том, что первое требует, чтобы реализации определяли и документировали последовательное поведение даже в тех случаях, когда ничего не могло сделать реализация. Разделительная линия между ними заключается не в том, будет ли полезно, чтобы реализации определяли поведение (писатели-компиляторы должны определять полезное поведение, когда это целесообразно, требуется ли Стандарт или нет), но могут ли быть реализации, когда определение поведения будет одновременно дорогостоящим и бесполезно. Суждение о том, что такие реализации могут существовать никоим образом, форма или форма, не подразумевает какого-либо суждения о полезности поддержки определенного поведения на других платформах.

К сожалению, с середины 1990-х годов авторы компилятора начали интерпретировать отсутствие поведенческих мандатов в качестве решения о том, что поведенческие гарантии не стоят затрат даже в областях приложений, где они жизненно важны, и даже в тех системах, где они стоят практически ничего. Вместо того, чтобы рассматривать UB в качестве приглашения для разумного суждения, авторы компиляторов начали рассматривать его как оправдание, чтобы этого не делать.

Например, учитывая следующий код:

int scaled_velocity(int v, unsigned char pow)
{
  if (v > 250)
    v = 250;
  if (v < -250)
    v = -250;
  return v << pow;
}

реализация двух дополнений не потребовала бы усилий вообще говоря, рассматривать выражение v << pow как сдвиг двух дополнений независимо от того, был ли v положительным или отрицательным.

Однако предпочтительная философия среди некоторых современных компиляторов предполагает, что, поскольку v может быть отрицательным, если программа будет участвовать в Undefined Поведении, нет никаких причин, чтобы программный клип был отрицательным диапазоном of v. Несмотря на то, что левое смещение отрицательных значений использовалось для каждого отдельного компилятора значимости, и большая часть существующего кода опирается на это поведение, современная философия будет интерпретировать тот факт, что в Стандарте говорится, что отрицательные значения сдвига слева являются UB как подразумевая, что составители компилятора должны быть свободны игнорировать это.

Реализация определена

Исполнители хотят, должны быть хорошо документированы, стандарт дает выбор, но обязательно компилирует

Unspecified -

То же, что и для реализации, но не документировано

Undefined -

Все может случиться, позаботься об этом.

Стандарт С++ n3337 § 1.3.10 поведение, определяемое реализацией

для хорошо сформированной программы и правильных данных это зависит от реализации и что каждый документ реализации

Иногда С++ Standard не налагает особого поведения на некоторые конструкции, но вместо этого говорит о том, что конкретное, четко определенное поведение должно быть выбрано и описано по конкретной реализации (версия библиотеки). Поэтому пользователь все равно может точно знать, как будет работать программа, даже если стандарт не описывает это.

Стандарт С++ n3337 § 1.3.24 undefined поведение

для которого настоящий международный стандарт не предъявляет никаких требований [Примечание: поведение Undefined можно ожидать, если этот международный Стандарт исключает любое явное определение поведения или когда программа использует ошибочную конструкцию или ошибочные данные. Допустимый undefinedповедение варьируется от полного игнорирования ситуации непредсказуемые результаты, вести себя во время перевода или программы исполнение в документированном виде, характерном для окружающей среды (с выдачей диагностического сообщения или без него), до завершения перевод или исполнение (с выдачей диагностического сообщение). Многие ошибочные программные конструкции не порождают undefinedповедение; они должны быть диагностированы. - конечная нота]

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

Стандарт С++ n3337 § 1.3.25 неуказанное поведение

для хорошо сформированной программы и правильных данных это зависит от реализации [Примечание: реализация не является требуется для документирования поведения. Диапазон возможных поведение обычно определяется этим Международным стандартом. - конец примечание]

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

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

Например, код:

struct foo {int x;} = {0};
int main(void)
{
  foo.x = 1;
  return foo.x-1;
}

использует lvalue типа int [ie foo.x ] для доступа к сохраненному значению объекта типа struct foo, хотя N1570 6.5p7 не содержит ничего, что позволило бы получить доступ к объекту типа struct foo за исключением того, что через lvalue типа struct foo или lvalue символьного типа, а также не содержит стандарт, который бы освобождал выражения типа struct-member-access из требований 6.5p7.

Очевидно, что любой компилятор, который не может обрабатывать простые выражения с использованием элементов структуры, должен рассматриваться как исключительно низкое качество и, вероятно, не подходит для большей части всего. Следовательно, разумно ожидать, что любой, кто стремится обеспечить качественную реализацию, поддержит такую конструкцию независимо от того, соответствует ли ей Стандарт. При условии, что авторам-компиляторам можно доверять, сделать добросовестные усилия для создания качественных компиляторов, которые подходят для их намеченных целей, и быть открытыми в отношении целей, для которых их компиляторы являются или не подходят, не было бы причин иметь стандартные отходы чернил пытаясь изложить то, что должно быть очевидно. Многие действия, которые должны иметь полезное и предсказуемое поведение, по сути, являются неопределенным поведением, потому что авторы стандартных доверенных авторов компилятора придерживаются разумного суждения, вместо того, чтобы использовать тот факт, что действия вызывают Undefined Behavior как оправдание, чтобы вычеркнуть окно,