Let\'s pretend my program contains a specific construct the C++ Standard states to be unspecified behavior. This basically means the implementation has to do something reasonabl
No, that's partly the reason undefined/implementation-defined behaviors exist in the standard. Undefined behavior isn't guaranteed to be the same between multiple compiles of the same source code on the same computer (say, with different optimization flags).
The committee clearly prefers well defined behavior. Implementation-defined behavior exists when the committee believes that multiple implementations exist for some concept, and there is no reason to prefer one over another in all cases. Undefined behavior exists when the committee believes it is too hard to keep any promises under reasonable implementations.
In many cases, undefined behavior is implemented as something without a check. The behavior is then up to the operating system, if there is one and if it notices something less-than kosher took place.
As an example, dereferencing memory that you don't own is undefined. In general the OS will kill your program if you do that. However if the stars align just right, you may manage to dereference memory that you don't own under C++'s rules (eg., you didn't get it from new
, or you already delete
d it) but that the OS believes you own. Sometimes you'll get a crash and sometimes you'll just corrupt memory somewhere else in your program, and sometimes you'll get away undetected (if the memory hasn't been handed back out, for instance).
Race conditions are considered undefined, and they are notorious for being different during different runs of the program. You'll probably get different behavior each time you smash your stack if your operating system does not notice.
Double delete
s are undefined. Generally they lead to crashes, but the fact that they are undefined means you can't rely on things crashing.