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 [thread] and [depr],
a conforming implementation shall,
within its resource limits as described in [implimits],
accept and correctly execute3
that program.
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.
Otherwise, if a program contains a violation of any diagnosable rule or an occurrence
of a construct described in this document as “conditionally-supported” when
the implementation does not support that construct, a conforming implementation
shall issue at least one diagnostic message.
During template argument deduction and substitution,
certain constructs that in other contexts require a diagnostic
are treated differently;
see [temp.deduct].
shall issue at least one diagnostic message for
each #warning or #error preprocessing directive
not following a #error preprocessing directive in
a preprocessing translation unit, and
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].
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
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).
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.