depish/cppdraft_translate
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Init

Browse Source
This commit is contained in:
Leonov Artur (Depish)
2025-10-25 03:02:53 +03:00
commit 043225d523
3416 changed files with 681196 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

390
cppdraft/intro/compliance.md Normal file
View File

@@ -0,0 +1,390 @@
[intro.compliance]
# 4 General principles [[intro]](./#intro)
## 4.1 Implementation compliance [intro.compliance]
### [4.1.1](#general) General [[intro.compliance.general]](intro.compliance.general)
[1](#general-1)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L742)
The set of[*diagnosable rules*](#def:diagnosable_rules "4.1.1 General [intro.compliance.general]") consists of all syntactic and semantic rules in this document
except for those rules containing an explicit notation that
“no diagnostic is required” or which are described as resulting in
“undefined behavior”[.](#general-1.sentence-1)
[2](#general-2)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L752)
Although this document states only requirements on C++
implementations, those requirements are often easier to understand if
they are phrased as requirements on programs, parts of programs, or
execution of programs[.](#general-2.sentence-1)
Such requirements have the following meaning:
- [(2.1)](#general-2.1)
If a program contains no violations of the rules in[[lex]](lex "5 Lexical conventions") through [[exec]](exec "33 Execution control library") as well as those specified in [[depr]](depr "Annex D (normative) Compatibility features"),
a conforming implementation shall accept and correctly execute[3](#footnote-3 "“Correct execution” can include undefined behavior and erroneous behavior, depending on the data being processed; see [intro.defs] and [intro.execution].") that program,
except when the implementation's limitations (see below) are exceeded[.](#general-2.1.sentence-1)
- [(2.2)](#general-2.2)
If a program contains a violation of a rule for which no diagnostic is required,
this document places no requirement on implementations
with respect to that program[.](#general-2.2.sentence-1)
- [(2.3)](#general-2.3)
Otherwise, if a program contains
* [(2.3.1)](#general-2.3.1)
a violation of any diagnosable rule,
* [(2.3.2)](#general-2.3.2)
a preprocessing translation unit with
a #warning preprocessing directive ([[cpp.error]](cpp.error "15.9 Diagnostic directives")),
* [(2.3.3)](#general-2.3.3)
an occurrence
of a construct described in this document as “conditionally-supported” when
the implementation does not support that construct, or
* [(2.3.4)](#general-2.3.4)
a contract assertion ([[basic.contract.eval]](basic.contract.eval "6.11.2 Evaluation"))
evaluated with a checking semantic
in a manifestly constant-evaluated context ([[expr.const]](expr.const "7.7 Constant expressions"))
resulting in a contract violation,
a conforming implementation
shall issue at least one diagnostic message[.](#general-2.3.sentence-1)
[*Note [1](#general-note-1)*:
During template argument deduction and substitution,
certain constructs that in other contexts require a diagnostic
are treated differently;
see [[temp.deduct]](temp.deduct "13.10.3 Template argument deduction")[.](#general-2.sentence-2)
— *end note*]
Furthermore, a conforming implementation
shall not accept
- [(2.4)](#general-2.4)
a preprocessing translation unit containing
a #error preprocessing directive ([[cpp.error]](cpp.error "15.9 Diagnostic directives")),
- [(2.5)](#general-2.5)
a translation unit with
a [*static_assert-declaration*](dcl.pre#nt:static_assert-declaration "9.1 Preamble [dcl.pre]") that fails ([[dcl.pre]](dcl.pre "9.1 Preamble")), or
- [(2.6)](#general-2.6)
a contract assertion evaluated with a terminating semantic ([[basic.contract.eval]](basic.contract.eval "6.11.2 Evaluation"))
in a manifestly constant-evaluated context ([[expr.const]](expr.const "7.7 Constant expressions"))
resulting in a contract violation[.](#general-2.sentence-3)
[3](#general-3)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L821)
For classes and class templates, the library Clauses specify partial
definitions[.](#general-3.sentence-1)
[Private members](class.access "11.8 Member access control [class.access]") are not
specified, but each implementation shall supply them to complete the
definitions according to the description in the library Clauses[.](#general-3.sentence-2)
[4](#general-4)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L830)
For functions, function templates, objects, and values, the library
Clauses specify declarations[.](#general-4.sentence-1)
Implementations shall supply definitions
consistent with the descriptions in the library Clauses[.](#general-4.sentence-2)
[5](#general-5)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L835)
A C++ translation unit ([[lex.phases]](lex.phases "5.2 Phases of translation"))
obtains access to the names defined in the library by
including the appropriate standard library header or importing
the appropriate standard library named header unit ([[using.headers]](using.headers "16.4.3.2 Headers"))[.](#general-5.sentence-1)
[6](#general-6)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L841)
The templates, classes, functions, and objects in the library have
external [linkage](basic.link "6.7 Program and linkage [basic.link]")[.](#general-6.sentence-1)
The implementation provides
definitions for standard library entities, as necessary, while combining
translation units to form a complete C++ program ([[lex.phases]](lex.phases "5.2 Phases of translation"))[.](#general-6.sentence-2)
[7](#general-7)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L848)
An implementation is either a[*hosted implementation*](#def:implementation,hosted "4.1.1 General [intro.compliance.general]") or a[*freestanding implementation*](#def:implementation,freestanding "4.1.1 General [intro.compliance.general]")[.](#general-7.sentence-1)
A freestanding
implementation is one in which execution may take place without the benefit of
an operating system[.](#general-7.sentence-2)
A hosted implementation
supports all the facilities described in this document, while
a freestanding implementation
supports the entire C++ language
described in [[lex]](lex "5 Lexical conventions") through [[cpp]](cpp "15 Preprocessing directives") and
the subset of the library facilities described in [[compliance]](compliance "16.4.2.5 Freestanding implementations")[.](#general-7.sentence-3)
[8](#general-8)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L862)
It isimplementation-defined
whether the implementation is a[*hardened implementation*](#def:implementation,hardened "4.1.1 General [intro.compliance.general]")[.](#general-8.sentence-1)
If it is a hardened implementation,
violating a hardened precondition
results in a contract violation ([[structure.specifications]](structure.specifications "16.3.2.4 Detailed specifications"))[.](#general-8.sentence-2)
[9](#general-9)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L871)
An implementation is encouraged to document its limitations in
the size or complexity of the programs it can successfully process,
if possible and where known[.](#general-9.sentence-1)
[[implimits]](implimits "Annex B (informative) Implementation quantities") lists some quantities that can be subject to limitations and
a potential minimum supported value for each quantity[.](#general-9.sentence-2)
[10](#general-10)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L878)
A conforming implementation may use an implementation-defined version
of the Unicode Standard that is a later version than the one
referenced in [[intro.refs]](intro.refs "2 Normative references")[.](#general-10.sentence-1)
[11](#general-11)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L883)
A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any well-formed program[.](#general-11.sentence-1)
Implementations are required to diagnose programs that use such
extensions that are ill-formed according to this document[.](#general-11.sentence-2)
Having done so, however, they can compile and execute such programs[.](#general-11.sentence-3)
[12](#general-12)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L891)
Each implementation shall include documentation that identifies all
conditionally-supported constructs that it does not support and defines all locale-specific characteristics[.](#general-12.sentence-1)[4](#footnote-4 "This documentation also defines implementation-defined behavior; see [intro.abstract].")
[3)](#footnote-3)[3)](#footnoteref-3)
“Correct execution” can include undefined behavior
and erroneous behavior, depending on
the data being processed; see [[intro.defs]](intro.defs "3 Terms and definitions") and [[intro.execution]](intro.execution "6.10.1 Sequential execution")[.](#footnote-3.sentence-1)
[4)](#footnote-4)[4)](#footnoteref-4)
This documentation also defines implementation-defined behavior;
see [[intro.abstract]](#intro.abstract "4.1.2 Abstract machine")[.](#footnote-4.sentence-1)
### [4.1.2](#intro.abstract) Abstract machine [[intro.abstract]](intro.abstract)
[1](#intro.abstract-1)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L904)
The semantic descriptions in this document define a
parameterized nondeterministic abstract machine[.](#intro.abstract-1.sentence-1)
This document
places no requirement on the structure of conforming
implementations[.](#intro.abstract-1.sentence-2)
In particular, they need not copy or emulate the
structure of the abstract machine[.](#intro.abstract-1.sentence-3)
Rather, conforming implementations are required to emulate (only) the observable
behavior of the abstract machine as explained below[.](#intro.abstract-1.sentence-4)[5](#footnote-5 "This provision is sometimes called the “as-if” rule, because an implementation is free to disregard any requirement of this document as long as the result is as if the requirement had been obeyed, as far as can be determined from the observable behavior of the program. For instance, an actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no side effects affecting the observable behavior of the program are produced.")
[2](#intro.abstract-2)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L929)
Certain aspects and operations of the abstract machine are described in this
document as implementation-defined behavior (for example,sizeof(int))[.](#intro.abstract-2.sentence-1)
These constitute the parameters of the abstract machine[.](#intro.abstract-2.sentence-2)
Each implementation shall include documentation describing its characteristics
and behavior in these respects[.](#intro.abstract-2.sentence-3)[6](#footnote-6 "This documentation also includes conditionally-supported constructs and locale-specific behavior. See [intro.compliance.general].")
Such documentation shall define the instance of the
abstract machine that corresponds to that implementation (referred to as the
“corresponding instance” below)[.](#intro.abstract-2.sentence-4)
[3](#intro.abstract-3)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L945)
Certain other aspects and operations of the abstract machine are
described in this document as unspecified behavior (for example,
order of evaluation of arguments in a function call ([[expr.call]](expr.call "7.6.1.3 Function call")))[.](#intro.abstract-3.sentence-1)
Where possible, this
document defines a set of allowable behaviors[.](#intro.abstract-3.sentence-2)
These
define the nondeterministic aspects of the abstract machine[.](#intro.abstract-3.sentence-3)
An instance
of the abstract machine can thus have more than one possible execution
for a given program and a given input[.](#intro.abstract-3.sentence-4)
[4](#intro.abstract-4)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L956)
Certain other operations are described in this document as
undefined behavior (for example, the effect of
attempting to modify a const object)[.](#intro.abstract-4.sentence-1)
[5](#intro.abstract-5)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L962)
Certain events in the execution of a program
are termed [*observable checkpoints*](#def:checkpoints,observable "4.1.2 Abstract machine [intro.abstract]")[.](#intro.abstract-5.sentence-1)
[*Note [1](#intro.abstract-note-1)*:
A call to std​::​observable_checkpoint ([[utility.undefined]](utility.undefined "22.2.9 Undefined behavior"))
is an observable checkpoint,
as are certain parts of
the evaluation of contract assertions ([[basic.contract]](basic.contract "6.11 Contract assertions"))[.](#intro.abstract-5.sentence-2)
— *end note*]
[6](#intro.abstract-6)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L972)
The [*defined prefix*](#def:prefix,defined "4.1.2 Abstract machine [intro.abstract]") of an execution
comprises the operations O for which for every undefined operation U there is an observable checkpoint C such that O happens before C andC happens before U[.](#intro.abstract-6.sentence-1)
[*Note [2](#intro.abstract-note-2)*:
The undefined behavior that arises from a data race ([[intro.races]](intro.races "6.10.2.2 Data races"))
occurs on all participating threads[.](#intro.abstract-6.sentence-2)
— *end note*]
A conforming implementation executing a well-formed program shall
produce the observable behavior
of the defined prefix
of one of the possible executions
of the corresponding instance
of the abstract machine with the
same program and the same input[.](#intro.abstract-6.sentence-3)
If the selected execution contains an undefined operation,
the implementation executing that program with that input
may produce arbitrary additional observable behavior afterwards[.](#intro.abstract-6.sentence-4)
If the execution contains an operation specified as having erroneous behavior,
the implementation is permitted to issue a diagnostic and
is permitted to terminate the execution
at an unspecified time after that operation[.](#intro.abstract-6.sentence-5)
[7](#intro.abstract-7)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L1003)
*Recommended practice*: An implementation should issue a diagnostic when such an operation is executed[.](#intro.abstract-7.sentence-1)
[*Note [3](#intro.abstract-note-3)*:
An implementation can issue a diagnostic
if it can determine that erroneous behavior is reachable
under an implementation-specific set of assumptions about the program behavior,
which can result in false positives[.](#intro.abstract-7.sentence-2)
— *end note*]
[8](#intro.abstract-8)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/intro.tex#L1013)
The following specify the[*observable behavior*](#def:behavior,observable "4.1.2 Abstract machine [intro.abstract]") of the program:
- [(8.1)](#intro.abstract-8.1)
Accesses through volatile glvalues are evaluated strictly according to the
rules of the abstract machine[.](#intro.abstract-8.1.sentence-1)
- [(8.2)](#intro.abstract-8.2)
Data is delivered to the host environment to be written into files (See also: ISO/IEC 9899:2024, 7.21.3)[.](#intro.abstract-8.2.sentence-1)
[*Note [4](#intro.abstract-note-4)*:
Delivering such data
is followed by an observable checkpoint ([[cstdio.syn]](cstdio.syn "31.13.1 Header <cstdio> synopsis"))[.](#intro.abstract-8.2.sentence-2)
Not all host environments provide access to file contents before program termination[.](#intro.abstract-8.2.sentence-3)
— *end note*]
- [(8.3)](#intro.abstract-8.3)
The input and output dynamics of interactive devices shall take
place in such a fashion that prompting output is actually delivered before a program waits for input[.](#intro.abstract-8.3.sentence-1)
What constitutes an interactive device isimplementation-defined[.](#intro.abstract-8.3.sentence-2)
[*Note [5](#intro.abstract-note-5)*:
More stringent correspondences between abstract and actual
semantics can be defined by each implementation[.](#intro.abstract-8.sentence-2)
— *end note*]
[5)](#footnote-5)[5)](#footnoteref-5)
This provision is
sometimes called the “as-if” rule, because an implementation is free to
disregard any requirement of this document as long as the result
is as if the requirement had been obeyed, as far as can be determined
from the observable behavior of the program[.](#footnote-5.sentence-1)
For instance, an actual
implementation need not evaluate part of an expression if it can deduce that its
value is not used and that noside effects affecting the
observable behavior of the program are produced[.](#footnote-5.sentence-2)
[6)](#footnote-6)[6)](#footnoteref-6)
This documentation also includes
conditionally-supported constructs and locale-specific behavior[.](#footnote-6.sentence-1)
See [[intro.compliance.general]](#general "4.1.1 General")[.](#footnote-6.sentence-2)