Исторически сложилось так, что определяемое реализацией поведение и неопределенное поведение представляли ситуации, в которых авторы стандарта ожидали, что люди, пишущие качественные реализации, будут использовать суждение, чтобы решить, какие поведенческие гарантии, если таковые имеются, будут полезны для программ в предполагаемой области приложения, работающей на предполагаемые цели. Потребности высокопроизводительного кода для обработки чисел сильно отличаются от потребностей низкоуровневого системного кода, и как UB, так и IDB предоставляют разработчикам компиляторов гибкость для удовлетворения этих различных потребностей. Ни одна из категорий не требует, чтобы реализации вели себя так, как это полезно для какой-либо конкретной цели или даже для какой-либо цели. Качественные реализации, которые претендуют на то, что они подходят для конкретной цели, однако, должны вести себя в соответствии с такой цельютребует ли Стандарт этого или нет .
Единственное различие между поведением, определяемым реализацией, и поведением с неопределенным поведением заключается в том, что первое требует, чтобы реализации определяли и документировали согласованное поведение даже в тех случаях, когда ничего, что могла бы сделать реализация, не было бы полезно . Разграничительная черта между ними заключается не в том, было бы полезно для реализаций определять поведение (авторы компилятора должны определять полезные поведения, когда это целесообразно, требует ли Стандарт этого или нет), но могут ли быть реализации, где определение поведения будет одновременно дорогостоящим и бесполезно . Суждение о том, что такие реализации могут существовать, никоим образом не формирует и не формирует какого-либо суждения о полезности поддержки определенного поведения на других платформах.
К сожалению, с середины 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может быть отрицательной только в том случае, если программа будет использовать неопределенное поведение, нет причин заставлять программу обрезать отрицательный диапазон v. Несмотря на то, что сдвиг влево отрицательных значений раньше поддерживался каждым значимым компилятором, и большое количество существующего кода опирается на такое поведение, современная философия интерпретирует тот факт, что Стандарт говорит, что отрицательные значения сдвига влево - это UB как подразумевая, что авторы компилятора должны свободно игнорировать это.