The set of
diagnosable rules
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”.
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.
If a program contains no violations of the rules in
[lex] through [exec] as well as those specified in [depr],
a conforming implementation shall accept and correctly execute3
that program,
except when the implementation's limitations (see below) are exceeded.
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.
During template argument deduction and substitution,
certain constructs that in other contexts require a diagnostic
are treated differently;
see [temp.deduct].
— end note]
Furthermore, a conforming implementation
shall not accept
For classes and class templates, the library Clauses specify partial
definitions.
Private members are not
specified, but each implementation shall supply them to complete the
definitions according to the description in the library Clauses.
A C++ translation unit ([lex.phases])
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]).
The templates, classes, functions, and objects in the library have
external linkage.
The implementation provides
definitions for standard library entities, as necessary, while combining
translation units to form a complete C++ program ([lex.phases]).
A freestanding
implementation is one in which execution may take place without the benefit of
an operating system.
A hosted implementation
supports all the facilities described in this document, while
a freestanding implementation
supports the entire C++ language
described in [lex] through [cpp] and
the subset of the library facilities described in [compliance].
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.
[implimits] lists some quantities that can be subject to limitations and
a potential minimum supported value for each quantity.
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 document.
Having done so, however, they can compile and execute such programs.
Each implementation shall include documentation that identifies all
conditionally-supported constructs
that it does not support and defines all locale-specific characteristics.4
“Correct execution” can include undefined behavior
and erroneous behavior, depending on
the data being processed; see [intro.defs] and [intro.execution].
Certain aspects and operations of the abstract machine are described in this
document as implementation-defined behavior (for example,
sizeof(int)).
These constitute the parameters of the abstract machine.
Each implementation shall include documentation describing its characteristics
and behavior in these respects.6
Such documentation shall define the instance of the
abstract machine that corresponds to that implementation (referred to as the
“corresponding instance” below).
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])).
Where possible, this
document defines a set of allowable behaviors.
These
define the nondeterministic aspects of the abstract machine.
An instance
of the abstract machine can thus have more than one possible execution
for a given program and a given input.
A conforming implementation executing a well-formed program shall
produce the same observable behavior as one of the possible executions
of the corresponding instance of the abstract machine with the
same program and the same input.
However, if any such execution contains an undefined operation, this document places no
requirement on the implementation executing that program with that input
(not even with regard to operations preceding the first undefined
operation).
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.
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.
At program termination, all data written into files shall be
identical to one of the possible results that execution of the program
according to the abstract semantics would have produced.
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.
What constitutes an interactive device is
implementation-defined.
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.