3 Terms and definitions [intro.defs]

For the purposes of this document, the terms and definitions given in ISO/IEC 2382-1:1993, the terms, definitions, and symbols given in ISO 80000-2:2009, and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
[definitions] defines additional terms that are used only in Clauses [library] through [thread] and Annex [depr].
Terms that are used only in a small portion of this document are defined where they are used and italicized where they are defined.

3.1 access [defns.access]

⟨execution-time action⟩ to read or modify the value of an object

3.2 argument [defns.argument]

⟨function call expression⟩ expression in the comma-separated list bounded by the parentheses ([expr.call])

3.3 argument [defns.argument.macro]

⟨function-like macro⟩ sequence of preprocessing tokens in the comma-separated list bounded by the parentheses ([cpp.replace])

3.4 argument [defns.argument.throw]

⟨throw expression⟩ the operand of throw

3.5 argument [defns.argument.templ]

⟨template instantiation⟩ constant-expression, type-id, or id-expression in the comma-separated list bounded by the angle brackets ([temp.arg])

3.6 block [defns.block]

a thread of execution that blocks is waiting for some condition (other than for the implementation to execute its execution steps) to be satisfied before it can continue execution past the blocking operation

3.7 conditionally-supported [defns.cond.supp]

program construct that an implementation is not required to support
[Note
:
Each implementation documents all conditionally-supported constructs that it does not support.
end note
]

3.8 diagnostic message [defns.diagnostic]

message belonging to an implementation-defined subset of the implementation's output messages

3.9 dynamic type [defns.dynamic.type]

⟨glvalue⟩ type of the most derived object to which the glvalue refers
[Example
:
If a pointer p whose static type is “pointer to class B” is pointing to an object of class D, derived from B, the dynamic type of the expression *p is “D.
References are treated similarly.
end example
]

3.10 dynamic type [defns.dynamic.type.prvalue]

⟨prvalue⟩ static type of the prvalue expression

3.11 ill-formed program [defns.ill.formed]

program that is not well-formed

3.12 implementation-defined behavior [defns.impl.defined]

behavior, for a well-formed program construct and correct data, that depends on the implementation and that each implementation documents

3.13 implementation limits [defns.impl.limits]

restrictions imposed upon programs by the implementation

3.14 locale-specific behavior [defns.locale.specific]

behavior that depends on local conventions of nationality, culture, and language that each implementation documents

3.15 multibyte character [defns.multibyte]

sequence of one or more bytes representing a member of the extended character set of either the source or the execution environment
[Note
:
The extended character set is a superset of the basic character set ([lex.charset]).
end note
]

3.16 parameter [defns.parameter]

⟨function or catch clause⟩ object or reference declared as part of a function declaration or definition or in the catch clause of an exception handler that acquires a value on entry to the function or handler

3.17 parameter [defns.parameter.macro]

⟨function-like macro⟩ identifier from the comma-separated list bounded by the parentheses immediately following the macro name

3.18 parameter [defns.parameter.templ]

⟨template⟩ member of a template-parameter-list

3.19 signature [defns.signature]

⟨function⟩ name, parameter-type-list, and enclosing namespace (if any)
[Note
:
Signatures are used as a basis for name mangling and linking.
end note
]

3.20 signature [defns.signature.templ]

⟨function template⟩ name, parameter-type-list, enclosing namespace (if any), return type, and template parameter list

3.21 signature [defns.signature.spec]

⟨function template specialization⟩ signature of the template of which it is a specialization and its template arguments (whether explicitly specified or deduced)

3.22 signature [defns.signature.member]

⟨class member function⟩ name, parameter-type-list, class of which the function is a member, cv-qualifiers (if any), and ref-qualifier (if any)

3.23 signature [defns.signature.member.templ]

⟨class member function template⟩ name, parameter-type-list, class of which the function is a member, cv-qualifiers (if any), ref-qualifier (if any), return type (if any), and template parameter list

3.24 signature [defns.signature.member.spec]

⟨class member function template specialization⟩ signature of the member function template of which it is a specialization and its template arguments (whether explicitly specified or deduced)

3.25 static type [defns.static.type]

type of an expression ([basic.types]) resulting from analysis of the program without considering execution semantics
[Note
:
The static type of an expression depends only on the form of the program in which the expression appears, and does not change while the program is executing.
end note
]

3.26 unblock [defns.unblock]

satisfy a condition that one or more blocked threads of execution are waiting for

3.27 undefined behavior [defns.undefined]

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.
Evaluation of a constant expression never exhibits behavior explicitly specified as undefined.
end note
]

3.28 unspecified behavior [defns.unspecified]

behavior, for a well-formed program construct and correct data, that depends on the implementation
[Note
:
The implementation is not required to document which behavior occurs.
The range of possible behaviors is usually delineated by this International Standard.
end note
]

3.29 well-formed program [defns.well.formed]

C++ program constructed according to the syntax rules, diagnosable semantic rules, and the one-definition rule.