也许简单的措辞比严格的标准定义更容易理解。

实现定义的行为: 语言说我们有数据类型。编译器供应商指定了他们应该使用的大小，并提供了他们所做的工作的文档。

未定义的行为: 你做错了什么。例如，int型中有一个非常大的值，但不适合char型。如何将该值放入char?其实没有办法!任何事情都可能发生，但最明智的做法是将int的第一个字节放入char类型。这样做分配第一个字节是错误的，但这是在引擎盖下发生的事情。

未指明的行为: 这两个函数哪个先执行?

void fun(int n, int m);

int fun1() {
    std::cout << "fun1";
    return 1;
}
int fun2() {
    std::cout << "fun2";
    return 2;
}

//...

fun(fun1(), fun2()); // which one is executed first?

语言没有指定计算值，从左到右还是从右到左!因此，未指定的行为可能会导致未定义的行为，也可能不会导致未定义的行为，但可以肯定的是，您的程序不应该产生未指定的行为。

@eSKay我认为你的问题值得编辑答案以澄清更多:)

For fun(fun1()， fun2());行为不是“实现定义的”吗?编译器必须选择一个或另一个过程，毕竟?

The difference between implementation-defined and unspecified, is that the compiler is supposed to pick a behavior in the first case but it doesn't have to in the second case. For example, an implementation must have one and only one definition of sizeof(int). So, it can't say that sizeof(int) is 4 for some portion of the program and 8 for others. Unlike unspecified behavior, where the compiler can say: "OK I am gonna evaluate these arguments left-to-right and the next function's arguments are evaluated right-to-left." It can happen in the same program, that's why it is called unspecified. In fact, C++ could have been made easier if some of the unspecified behaviors were specified. Take a look here at Dr. Stroustrup's answer for that:

It is claimed that the difference between what can be produced giving the compiler this freedom and requiring "ordinary left-to-right evaluation" can be significant. I'm unconvinced, but with innumerable compilers "out there" taking advantage of the freedom and some people passionately defending that freedom, a change would be difficult and could take decades to penetrate to the distant corners of the C and C++ worlds. I am disappointed that not all compilers warn against code such as ++i+i++. Similarly, the order of evaluation of arguments is unspecified. IMO far too many "things" are left undefined, unspecified, that's easy to say and even to give examples of, but hard to fix. It should also be noted that it is not all that difficult to avoid most of the problems and produce portable code.

也许简单的措辞比严格的标准定义更容易理解。

实现定义的行为: 语言说我们有数据类型。编译器供应商指定了他们应该使用的大小，并提供了他们所做的工作的文档。

未定义的行为: 你做错了什么。例如，int型中有一个非常大的值，但不适合char型。如何将该值放入char?其实没有办法!任何事情都可能发生，但最明智的做法是将int的第一个字节放入char类型。这样做分配第一个字节是错误的，但这是在引擎盖下发生的事情。

未指明的行为: 这两个函数哪个先执行?

void fun(int n, int m);

int fun1() {
    std::cout << "fun1";
    return 1;
}
int fun2() {
    std::cout << "fun2";
    return 2;
}

//...

fun(fun1(), fun2()); // which one is executed first?

语言没有指定计算值，从左到右还是从右到左!因此，未指定的行为可能会导致未定义的行为，也可能不会导致未定义的行为，但可以肯定的是，您的程序不应该产生未指定的行为。

@eSKay我认为你的问题值得编辑答案以澄清更多:)

For fun(fun1()， fun2());行为不是“实现定义的”吗?编译器必须选择一个或另一个过程，毕竟?

The difference between implementation-defined and unspecified, is that the compiler is supposed to pick a behavior in the first case but it doesn't have to in the second case. For example, an implementation must have one and only one definition of sizeof(int). So, it can't say that sizeof(int) is 4 for some portion of the program and 8 for others. Unlike unspecified behavior, where the compiler can say: "OK I am gonna evaluate these arguments left-to-right and the next function's arguments are evaluated right-to-left." It can happen in the same program, that's why it is called unspecified. In fact, C++ could have been made easier if some of the unspecified behaviors were specified. Take a look here at Dr. Stroustrup's answer for that:

It is claimed that the difference between what can be produced giving the compiler this freedom and requiring "ordinary left-to-right evaluation" can be significant. I'm unconvinced, but with innumerable compilers "out there" taking advantage of the freedom and some people passionately defending that freedom, a change would be difficult and could take decades to penetrate to the distant corners of the C and C++ worlds. I am disappointed that not all compilers warn against code such as ++i+i++. Similarly, the order of evaluation of arguments is unspecified. IMO far too many "things" are left undefined, unspecified, that's easy to say and even to give examples of, but hard to fix. It should also be noted that it is not all that difficult to avoid most of the problems and produce portable code.

未定义行为vs.未指定行为有一个简短的描述。

他们最后的总结是:

总而言之，未指定的行为通常是不应该发生的 担心，除非你的软件被要求是可移植的。 相反，未定义的行为总是不受欢迎的，也不应该这样做 发生。

未定义的行为是丑陋的——比如“好的、坏的和丑陋的”。

好:一个能够编译并正常工作的程序。

坏的:有错误的程序，这种错误编译器可以检测到并报错。

丑陋的:一个程序有一个错误，编译器不能检测和警告，这意味着程序编译，可能在某些时候正确工作，但也在某些时候奇怪地失败。这就是未定义行为。

一些程序语言和其他正式系统努力限制“不确定性的鸿沟”——也就是说，它们试图安排事情，使大多数或所有程序不是“好”就是“坏”，只有极少数程序是“丑”的。然而，这是C语言的一个特征，它的“不确定性的鸿沟”相当宽。

来自官方的C基本原理文档

The terms unspecified behavior, undefined behavior, and implementation-defined behavior are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits quality of implementation to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of conformance to the Standard. Appendix F to the Standard catalogs those behaviors which fall into one of these three categories. Unspecified behavior gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program. Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. Implementation-defined behavior gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response.

好吧，这基本上是直接从标准复制粘贴

3.4.1 1 implementation-defined behavior unspecified behavior where each implementation documents how the choice is made 2 EXAMPLE An example of implementation-defined behavior is the propagation of the high-order bit when a signed integer is shifted right. 3.4.3 1 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements 2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). 3 EXAMPLE An example of undefined behavior is the behavior on integer overflow. 3.4.4 1 unspecified behavior use of an unspecified value, or other behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance 2 EXAMPLE An example of unspecified behavior is the order in which the arguments to a function are evaluated.