Історично і поведінка, визначена реалізацією, і не визначена поведінка представляли ситуації, в яких автори Стандарту очікували, що люди, які пишуть якісні реалізації, будуть використовувати судження, щоб вирішити, які гарантії поведінки, якщо такі є, будуть корисні для програм у передбачуваному полі застосування, що працює на цільові цілі. Потреби в висококласному коді скорочення чисел дуже відрізняються від вимог системного коду низького рівня, і 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 як маючи на увазі, що автори-компілятори повинні сміливо ігнорувати це.