In der Vergangenheit stellten sowohl implementierungsdefiniertes Verhalten als auch undefiniertes Verhalten Situationen dar, in denen die Autoren des Standards erwarteten, dass Personen, die Qualitätsimplementierungen schreiben, mit Urteilsvermögen entscheiden würden, welche Verhaltensgarantien, falls vorhanden, für Programme in dem beabsichtigten Anwendungsfeld nützlich sind, das auf dem Programm ausgeführt wird beabsichtigte Ziele. Die Anforderungen von High-End-Code für das Knacken von Zahlen unterscheiden sich erheblich von denen von Low-Level-Systemcode, und sowohl UB als auch IDB bieten Compiler-Autoren Flexibilität, um diese unterschiedlichen Anforderungen zu erfüllen. Keine der beiden Kategorien schreibt vor, dass sich Implementierungen so verhalten, dass sie für einen bestimmten Zweck oder sogar für einen beliebigen Zweck nützlich sind. Qualitätsimplementierungen, die behaupten, für einen bestimmten Zweck geeignet zu sein, sollten sich jedoch in einer Weise verhalten, die diesem Zweck angemessen istob der Standard dies erfordert oder nicht .
Der einzige Unterschied zwischen implementierungsdefiniertem Verhalten und nicht definiertem Verhalten besteht darin, dass erstere erfordern, dass Implementierungen ein konsistentes Verhalten definieren und dokumentieren, selbst wenn nichts, was die Implementierung möglicherweise tun könnte, nützlich wäre . Die Trennlinie zwischen ihnen besteht nicht darin, ob es für Implementierungen im Allgemeinen nützlich wäre, Verhaltensweisen zu definieren (Compiler-Autoren sollten nützliche Verhaltensweisen definieren, wenn dies nach dem Standard erforderlich ist oder nicht), sondern ob es Implementierungen geben könnte, bei denen das Definieren eines Verhaltens gleichzeitig kostspielig wäre und nutzlos . Ein Urteil darüber, dass solche Implementierungen existieren könnten, impliziert in keiner Weise, Form oder Form ein Urteil über die Nützlichkeit der Unterstützung eines definierten Verhaltens auf anderen Plattformen.
Leider haben Compiler-Autoren seit Mitte der neunziger Jahre damit begonnen, das Fehlen von Verhaltensmandaten als ein Urteil zu interpretieren, dass Verhaltensgarantien die Kosten selbst in Anwendungsbereichen, in denen sie von entscheidender Bedeutung sind, und sogar auf Systemen, in denen sie praktisch nichts kosten, nicht wert sind. Anstatt UB als Aufforderung zu angemessenem Urteilsvermögen zu behandeln, haben Compiler-Autoren damit begonnen, dies als Entschuldigung dafür zu betrachten, dies nicht zu tun.
Beispiel: Geben Sie den folgenden Code ein:
int scaled_velocity(int v, unsigned char pow)
{
if (v > 250)
v = 250;
if (v < -250)
v = -250;
return v << pow;
}
Eine Zwei-Komplement-Implementierung müsste keinerlei Aufwand erfordern, um den Ausdruck v << powals Zwei-Komplement-Verschiebung zu behandeln , ohne Rücksicht darauf, ob er vpositiv oder negativ ist.
Die bevorzugte Philosophie einiger heutiger Compiler-Autoren würde jedoch darauf vhinweisen, dass es keinen Grund gibt, das Programm den negativen Bereich von abschneiden zu lassen , da es nur negativ sein kann, wenn sich das Programm auf undefiniertes Verhalten einlässt v. Obwohl die Linksverschiebung negativer Werte früher von jedem einzelnen Compiler von Bedeutung unterstützt wurde und eine große Menge vorhandenen Codes auf diesem Verhalten beruht, würde die moderne Philosophie die Tatsache interpretieren, dass der Standard sagt, dass linksverschiebende negative Werte UB sind als Dies bedeutet, dass Compiler-Autoren dies ignorieren sollten.