4 General principles [intro]

4.1 Implementation compliance [intro.compliance]

4.1.1 General [intro.compliance.general]

1
#
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”.
2
#
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.
Such requirements have the following meaning:
  • (2.1)
    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.
  • (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.
  • (2.3)
    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.
[Note 1: 
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
  • (2.4)
    shall not accept a preprocessing translation unit containing a #error preprocessing directive ([cpp.error]),
  • (2.5)
    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
  • (2.6)
    shall not accept a translation unit with a static_assert-declaration that fails ([dcl.pre]).
3
#
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.
4
#
For functions, function templates, objects, and values, the library Clauses specify declarations.
Implementations shall supply definitions consistent with the descriptions in the library Clauses.
5
#
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]).
6
#
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]).
7
#
Two kinds of implementations are defined: a hosted implementation and a freestanding implementation.
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].
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 document.
Having done so, however, they can compile and execute such programs.
9
#
Each implementation shall include documentation that identifies all conditionally-supported constructs that it does not support and defines all locale-specific characteristics.4
3)3)
“Correct execution” can include undefined behavior, depending on the data being processed; see [intro.defs] and [intro.execution].
4)4)
This documentation also defines implementation-defined behavior; see [intro.abstract].

4.1.2 Abstract machine [intro.abstract]

1
#
The semantic descriptions in this document define a parameterized nondeterministic abstract machine.
This document places no requirement on the structure of conforming implementations.
In particular, they need not copy or emulate the structure of the abstract machine.
Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.5
2
#
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).
3
#
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.
4
#
Certain other operations are described in this document as undefined behavior (for example, the effect of attempting to modify a const object).
[Note 1: 
This document imposes no requirements on the behavior of programs that contain undefined behavior.
— end note]
5
#
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).
6
#
The least requirements on a conforming implementation are:
  • (6.1)
    Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine.
  • (6.2)
    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.
  • (6.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.
    What constitutes an interactive device is implementation-defined.
These collectively are referred to as the observable behavior of the program.
[Note 2: 
More stringent correspondences between abstract and actual semantics can be defined by each implementation.
— end note]
5)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.
6)6)
This documentation also includes conditionally-supported constructs and locale-specific behavior.

4.2 Structure of this document [intro.structure]

1
#
[lex] through [cpp] describe the C++ programming language.
That description includes detailed syntactic specifications in a form described in [syntax].
For convenience, [gram] repeats all such syntactic specifications.
2
#
[support] through [thread] and [depr] (the library clauses) describe the C++ standard library.
That description includes detailed descriptions of the entities and macros that constitute the library, in a form described in [library].
3
#
[implimits] recommends lower bounds on the capacity of conforming implementations.
4
#
[diff] summarizes the evolution of C++ since its first published description, and explains in detail the differences between C++ and C.
Certain features of C++ exist solely for compatibility purposes; [depr] describes those features.

4.3 Syntax notation [syntax]

1
#
In the syntax notation used in this document, syntactic categories are indicated by italic, sans-serif type, and literal words and characters in constant width type.
Alternatives are listed on separate lines except in a few cases where a long set of alternatives is marked by the phrase “one of”.
If the text of an alternative is too long to fit on a line, the text is continued on subsequent lines indented from the first one.
An optional terminal or non-terminal symbol is indicated by the subscript “”, so
{ expression }
indicates an optional expression enclosed in braces.
2
#
Names for syntactic categories have generally been chosen according to the following rules:
  • (2.1)
    X-name is a use of an identifier in a context that determines its meaning (e.g., class-name, typedef-name).
  • (2.2)
    X-id is an identifier with no context-dependent meaning (e.g., qualified-id).
  • (2.3)
    X-seq is one or more X's without intervening delimiters (e.g., declaration-seq is a sequence of declarations).
  • (2.4)
    X-list is one or more X's separated by intervening commas (e.g., identifier-list is a sequence of identifiers separated by commas).