blocks|key|3027274|text|我能找到的唯一相关的引述是，需要一个实现来诊断格式错误的程序，但它可以完成编译：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3027275|1.4实施合规性intro.compliance|3027276|3027277|+8)一致性实现可以有扩展(包括附加库函数)，前提是它们不会改变任何格式良好的程序的行为。根据本国际标准，需要实现来诊断使用此类扩展的程序。然而，这样做之后，他们就可以编译和执行这样的程序了。|blockquote|3027278|3027279|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|M|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|N|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|J|$]]

The only relevant quote I could find says that an implementation is required to diagnose an ill-formed program, but it can finish compiling it:

<h3>1.4 Implementation compliance [intro.compliance]</h3>

<blockquote>
 8) A conforming implementation may have extensions (including additional
 library functions), provided they do not alter the behavior of any
 well-formed program. Implementations are required to diagnose programs
 that use such extensions that are ill-formed according to this
 International Standard. Having done so, however, they can compile and
 execute such programs.
</blockquote>

blocks|key|194301|text|引用intro.compliance§2：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|194302|194303|blockquote|194304|194305|194306|如果程序不包含违反本国际标准中的规则的情况，则符合要求的实现应在其资源限制内接受并正确执行该程序。|unordered-list-item|194307|如果程序包含违反任何可诊断规则的情况，或者在实现不支持该构造时出现了在本标准中描述为“有条件支持”的构造，则符合要求的实现应至少发出一条诊断消息。|194308|如果程序包含不需要诊断的规则冲突，则本国际标准对该程序的实现没有要求。|194309|194310|我在标准中没有找到任何其他相关的段落。如果我们将其与defns.undefined结合使用|194311|194312|+未定义的行为|offset|length|style|BOLD|194313|194314|本国际标准没有规定要求的行为|194315|注意:如果本国际标准省略了行为的任何明确定义，或者程序使用了错误的构造或错误的数据，则可能会出现未定义的行为。允许的未定义行为的范围从完全忽略具有不可预测结果的情况，到在翻译或程序执行期间以环境的记录方式(具有或不具有诊断消息的发布)的行为，到终止转换或执行(具有诊断消息的发布)。许多错误的程序构造不会产生未定义的行为；它们需要进行诊断。-end笔记|194316|194317|我会说我们达到了“发出诊断消息，并且进一步的行为是未定义的”，因为标准没有更多地说明这一点。|194318|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|1|6|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|C|3|-4|5|D|7|19|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|1C|8|@]|9|@]|A|$]]|$1|J|3|K|5|I|7|1D|8|@]|9|@]|A|$]]|$1|L|3|M|5|I|7|1E|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|R|3|S|5|D|7|1I|8|@$T|1J|U|1K|V|W]]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1M|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1N|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|1P|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]]|16|$]]

Quoting [intro.compliance]§2:

<blockquote>
 <ul>
 <li>If a program contains no violations of the rules in this International Standard, a conforming implementation shall, within its
 resource limits, accept and correctly execute that program.</li>
 <li>If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as
 “conditionally-supported” when the implementation does not support
 that construct, a conforming implementation shall issue at least one
 diagnostic message.</li>
 <li>If a program contains a violation of a rule for which no diagnostic is required, this International Standard places no requirement on
 implementations with respect to that program.</li>
 </ul>
</blockquote>

I haven't found any other relevant passages in the standard. If we combine this with [defns.undefined]:

<blockquote>
 undefined behavior
 
 behavior for which this International Standard imposes no requirements
 
 [ Note: Undefined behavior may be expected when this International
 Standard omits any explicit definition of behavior or when a program
 uses an erroneous construct or erroneous data. Permissible 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). Many erroneous program constructs do not engender undefined
 behavior; they are required to be diagnosed. -end note ]
</blockquote>

I'd say we arrive at "issue a diagnostic message and further the behaviour is undefined," because the standard doesn't say anything more about it.

blocks|key|190140|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|190141|当遇到格式错误的程序时，C%2B%2B实现是否需要执行特定的操作，或者C%2B%2B实现行为是否未定义？|blockquote|190142|190143|190144|如果标准未另行规定，则实现应发出诊断消息(错误或警告)。但是，对于某些违规行为，标准明确规定不需要诊断。在这种情况下，程序是病态的，但实现不需要告诉用户-通常是因为在一般情况下这样做太难了。|offset|length|style|BOLD|190145|例如，关于One+Definition规则，参见C%2B%2B11标准的第3.2/4段：|190146|190147|每个程序应包含该程序中使用的每个非内联函数或变量的一个定义；不需要诊断。|190148|190149|190150|关于遇到违反规则时的实施要求，第1.4/2段规定：|190151|190152|+...|190153|190154|-如果程序不违反本国际标准中的规则，则符合要求的实现应在其资源限制内接受并正确执行该程序。|190155|-如果程序违反了任何可诊断规则，或当实施不支持该构造时，出现了本标准中描述为“有条件支持”的构造，则一致性实施应发出至少一条诊断消息。|190156|-如果程序包含不需要诊断的违反规则，则本国际标准对该程序的实现没有任何要求。|190157|190158|同样相关的是第1.4/1段，该段解释了上文引用的段落中“可诊断规则”的含义：|190159|190160|可诊断规则集由本国际标准中的所有语法和语义规则组成，但包含“不需要诊断”或被描述为导致“未定义的行为”的明确表示法的规则除外。|190161|190162|190163|因此，总结一下:如果一个格式错误的程序包含一个可诊断的冲突，而标准没有明确规定“不需要诊断”，那么符合标准的实现应该发出诊断。|190164|entityMap^0|0|0|0|0|0|K|0|0|0|U|5|0|0|0|0|0|0|0|0|1|E|1E|G|0|0|0|0|0|C|B|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|1G|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1H|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|1I|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|1J|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|1K|7|@$H|1L|I|1M|J|K]]|8|@]|9|$]]|$1|L|3|M|4|5|6|1N|7|@]|8|@]|9|$]]|$1|N|3|-4|4|5|6|1O|7|@]|8|@]|9|$]]|$1|O|3|P|4|C|6|1P|7|@$H|1Q|I|1R|J|K]]|8|@]|9|$]]|$1|Q|3|-4|4|5|6|1S|7|@]|8|@]|9|$]]|$1|R|3|-4|4|5|6|1T|7|@]|8|@]|9|$]]|$1|S|3|T|4|5|6|1U|7|@]|8|@]|9|$]]|$1|U|3|-4|4|5|6|1V|7|@]|8|@]|9|$]]|$1|V|3|W|4|C|6|1W|7|@]|8|@]|9|$]]|$1|X|3|-4|4|5|6|1X|7|@]|8|@]|9|$]]|$1|Y|3|Z|4|5|6|1Y|7|@]|8|@]|9|$]]|$1|10|3|11|4|5|6|1Z|7|@$H|20|I|21|J|K]|$H|22|I|23|J|K]]|8|@]|9|$]]|$1|12|3|13|4|5|6|24|7|@]|8|@]|9|$]]|$1|14|3|-4|4|5|6|25|7|@]|8|@]|9|$]]|$1|15|3|16|4|5|6|26|7|@]|8|@]|9|$]]|$1|17|3|-4|4|5|6|27|7|@]|8|@]|9|$]]|$1|18|3|19|4|C|6|28|7|@$H|29|I|2A|J|K]]|8|@]|9|$]]|$1|1A|3|-4|4|5|6|2B|7|@]|8|@]|9|$]]|$1|1B|3|-4|4|5|6|2C|7|@]|8|@]|9|$]]|$1|1C|3|1D|4|5|6|2D|7|@]|8|@]|9|$]]|$1|1E|3|-4|4|5|6|2E|7|@]|8|@]|9|$]]]|1F|$]]

<blockquote>
 Is the C++ implementation required to do something specific when it encounters an ill-formed program or is the C++ implementation behavior just undefined?
</blockquote>

If the Standard does not specify otherwise, an implementation should emit a diagnostic message (error or warning). However, for some violations the Standard explicitly specifies that no diagnostic is required. In this case, the program is ill-formed, but implementations are not required to tell the user - usually, because doing so in the general case would be too difficult.

Concerning the One Definition Rule, for example, see Paragraph 3.2/4 of the C++11 Standard:

<blockquote>
 Every program shall contain exactly one definition of every non-inline function or variable that is odr-used
 in that program; no diagnostic required.
</blockquote>

Regarding the requirements on implementations when encountering a violation of a rule, Paragraph 1.4/2 specifies:

<blockquote>
 [...]
 
 — If a program contains no violations of the rules in this International Standard, a conforming implementation
 shall, within its resource limits, accept and correctly execute that program.
 
 — If a program contains a violation of any diagnosable rule or an occurrence of a construct described in
 this Standard as “conditionally-supported” when the implementation does not support that construct,
 a conforming implementation shall issue at least one diagnostic message.
 
 — If a program contains a violation of a rule for which no diagnostic is required, this International
 Standard places no requirement on implementations with respect to that program.
</blockquote>

Also relevant is Paragraph 1.4/1, which explains what is meant by "diagnosable rules" in the Paragraph quoted above:

<blockquote>
 The set of diagnosable rules consists of all syntactic and semantic rules in this International Standard except
 for those rules containing an explicit notation that “no diagnostic is required” or which are described as
 resulting in “undefined behavior.”
</blockquote>

So to sum it up: if an ill-formed program contains a diagnosable violation for which the Standard does not explicitly specify "no diagnostic required", conforming implementations should emit a diagnostic.

blocks|key|194393|text|(首先，我为我的英语道歉)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|194394|标准，在§1.4.2中说：|194395|194396|如果程序包含违反任何可诊断规则的情况...一致性实现应至少发出一条诊断消息。|blockquote|194397|194398|194399|格式不良的程序的定义是“不是格式良好的程序”(§1.3.9)，格式良好的程序是(§1.3.26)：|194400|根据语法规则、可诊断语义规则和One+Definition规则构造的|194401|+C%2B%2B程序|194402|194403|194404|因此，一个格式错误的程序确实暗中违反了“某些”规则。如果规则R具有以下结构：|194405|194406|如果一个程序具有属性P，则它是一个格式错误的程序。|194407|194408|194409|当程序具有这样的属性P时，它确实隐含地违反了规则(根据病态程序的定义)，尽管不清楚哪个规则是被违反的，因为R本身没有(从严格的逻辑角度来看)。|194410|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|15|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|18|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|19|8|@]|9|@]|A|$]]|$1|N|3|O|5|G|7|1A|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1D|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|U|3|V|5|G|7|1F|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1I|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|11|$]]

(First of all, sorry for my English)

The Standard, in §1.4.2 says:

<blockquote>
 If a program contains a violation of any diagnosable rule [...] a conforming implementation shall issue at least one diagnostic message.
</blockquote>

The definition of a ill-formed program is "a program that is not well formed" (§1.3.9), and a well-formed program is (§1.3.26):

<blockquote>
 C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Definition Rule
</blockquote>

So, a ill-formed program does implicitly violate "some" rule. If a rule R has the following structure:

<blockquote>
 If a program has property P, it is an ill-formed program.
</blockquote>

When a program has such property P, it does implicitly violate a rule (by definition of an ill-formed program), although it isn't clear which rule is the one which are being violated, since R itself doesn't (from a strictly logical point of view).

C++03 Standard defines well-formed program (1.3.14 [defns.well.formed]) as

<blockquote>
 a C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Definition Rule (3.2)
</blockquote>

It further defines an ill-formed program (1.3.4 [defns.ill.formed]) as

<blockquote>
 input to a C++ implementation that is not a well-formed program (1.3.14)
</blockquote>

and the Standard is full of statements such as "if X then the program is ill-formed" for example (2.13.1/3):

<blockquote>
 A program is ill-formed if one of its translation units contains an integer literal that cannot be represented by any of the allowed types.
</blockquote>

Yet I haven't found what the C++ implementation is required to do with ill-formed programs.

Suppose I have an ill-formed program. Now what?

Is the C++ implementation required to do something specific when it encounters an ill-formed program or is the C++ implementation behavior just undefined?

What is the C++ compiler required to do with ill-formed programs according to the Standard?

C++03标准将格式良好的程序(1.3.14 defns.well.formed)定义为根据语法规则、可诊断语义规则和一个定义规则(3.2)构造的C++程序它进一步将格式错误的程序(1.3.4 defns.ill.formed)定义为对不是格式良好的程序的C++实现的输入(1.3.14)标准中充满了诸如“如果X，那么程...

问根据标准，C++编译器需要对格式错误的程序做什么？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问根据标准，C++编译器需要对格式错误的程序做什么？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问根据标准，C++编译器需要对格式错误的程序做什么？
EN