我通常说“编译器警告”，“编译器错误”。因此，当听到“编译器诊断消息”或“编译器诊断”消息时，我不确定它们是通常的“编译器警告”，“编译器错误”还是其他内容？
答案 0 :(得分：6)
标准实际上将诊断消息定义为
属于实现定义子集的消息 实现的输出消息
这是任何消息，实现选择选择以任何形式呈现。打印到控制台的警告和错误均属于此定义。但它不仅限于控制台，甚至不只是警告或错误。例如，一种实现可以选择在弹出窗口中显示“信息”消息。这也是潜在的诊断消息。
答案 1 :(得分：0)
“诊断消息”是C ++标准中的术语。可能是当有人说“编译器诊断”时，他们含糊地想到了该术语，但没有正确地应用它。
该标准针对代码中不符合该标准要求的内容提供了几种类别，并且允许编译器响应的方式取决于错误适合的类别。
该标准中的大多数要求都在“ 可诊断规则的集合”中。这些规则包含标准中的所有语法和语义要求，但明确标记为“不需要诊断”的规则和描述为导致“未定义行为”的规则除外。 （来自[intro.compliance] / 1）。
如果程序违反了可诊断的规则，则符合规范的实现“应至少发布一条诊断消息”。
因此，从广义上讲，大多数编码错误都需要诊断消息。现在，剩下的问题是什么构成“诊断消息”，并且在标准中将其定义为“属于实现的输出消息的实现定义子集的消息”。
这意味着编译器可以与您交谈，或者只需要与您交谈，除了检测到某些编码错误时，它必须对您说些什么。
因此，当编译器告诉您应该在||中的if (a && b || c && d)操作周围加上括号时，这只是胡说八道。该代码是有效的，并且其含义已得到很好的定义，它只是为您提供样式建议（以及不良建议）。
当它告诉您它不知道x中typedef int foo; fo0 x;的类型时，它正在响应可诊断的错误。如果实现的文档告诉您该消息是诊断消息，那么就是这样。通常，这就是编译器的工作。
请注意，不需要编译器拒绝编译具有可诊断错误的代码。 仅要求是发出诊断消息。完成此操作后，编译器可以自由地继续编译代码，并获得特定于实现的结果。这种灵活性的主要原因是它允许特定于编译器的扩展。
编译器通常区分警告和错误；标准没有。它确实要求，当提供的代码不违反任何标准要求时，并且如果程序太大（模糊意义上），则编译器必须创建一个可执行程序。正式地，这就是“如果程序不违反本国际标准中的规则，则合格的实现应在其资源限制内接受并正确执行该程序。” [intro.compliance] / 2。
答案 2 :(得分：0)
许多标准中的许多价值不仅仅在于它们要求所有符合标准的实例要做的事情，而且还在于他们建议在可行的情况下应该执行质量实例的事情。但是，C89标准的作者竭尽所能避免对不需要的任何内容提供此类建议。如果C89推荐例如该实现以与全局传递关系一致的方式处理指针上的关系运算符，这可能被认为暗示着这种做法不切实际的实现要差一些。
该标准的作者不想禁止有效地处理早于该标准且不满足其要求的代码的符合标准的实现，但也不想特别暗示该实现应接受不符合要求的新代码。符合要求。符合要求的实现必须有意义地处理至少一个程序的要求，或者给定实现的源文本违反编译时约束的要求必须产生至少一个诊断。在硬性要求和建议之间闪避。据推测，一个高质量的实现应该能够有效地处理单个人为的（可能是无用的）源文本以外的东西，并且应该产生一些比“警告：”更有用的诊断信息：该实现不会输出除此以外的任何诊断信息。 “，但是一个实现可以满足标准，而不会超出上述范围。