3 Terms and definitions [intro.defs]

1
#
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.
2
#
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
3
#
[definitions] defines additional terms that are used only in [library] through [thread] and [depr].
4
#
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[defns.access]access

⟨execution-time action⟩ read ([conv.lval]) or modify ([expr.ass], [expr.post.incr], [expr.pre.incr]) the value of an object
[Note
:
Only objects of scalar type can be accessed.
Attempts to read or modify an object of class type typically invoke a constructor or assignment operator; such invocations do not themselves constitute accesses, although they may involve accesses of scalar subobjects.
— end note
]

3.2[defns.argument]argument

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

3.3[defns.argument.macro]argument

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

3.4[defns.argument.throw]argument

⟨throw expression⟩ operand of throw

3.5[defns.argument.templ]argument

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

3.6[defns.block]block

⟨execution⟩ wait for some condition (other than for the implementation to execute the execution steps of the thread of execution) to be satisfied before continuing execution past the blocking operation

3.7[defns.block.stmt]block

⟨statement⟩ compound statement ([stmt.block])

3.8[defns.cond.supp]conditionally-supported

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.9[defns.diagnostic]diagnostic message

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

3.10[defns.dynamic.type]dynamic type

⟨glvalue⟩ type of the most derived object ([intro.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.11[defns.dynamic.type.prvalue]dynamic type

⟨prvalue⟩ static type of the prvalue expression

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

program that is not well-formed

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

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

3.14[defns.impl.limits]implementation limits

restrictions imposed upon programs by the implementation

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

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

3.16[defns.multibyte]multibyte character

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.17[defns.parameter]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.18[defns.parameter.macro]parameter

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

3.19[defns.parameter.templ]parameter

⟨template⟩ member of a template-parameter-list

3.20[defns.signature]signature

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

3.21[defns.signature.friend]signature

⟨non-template friend function with trailing requires-clause⟩ name, parameter-type-list ([dcl.fct]), enclosing class, and trailing requires-clause ([dcl.decl])

3.22[defns.signature.templ]signature

⟨function template⟩ name, parameter-type-list ([dcl.fct]), enclosing namespace (if any), return type, template-head, and trailing requires-clause ([dcl.decl]) (if any)

3.23[defns.signature.templ.friend]signature

⟨friend function template with constraint involving enclosing template parameters⟩ name, parameter-type-list ([dcl.fct]), return type, enclosing class, template-head, and trailing requires-clause ([dcl.decl]) (if any)

3.24[defns.signature.spec]signature

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

3.25[defns.signature.member]signature

⟨class member function⟩ name, parameter-type-list ([dcl.fct]), class of which the function is a member, cv-qualifiers (if any), ref-qualifier (if any), and trailing requires-clause ([dcl.decl]) (if any)

3.26[defns.signature.member.templ]signature

⟨class member function template⟩ name, parameter-type-list ([dcl.fct]), class of which the function is a member, cv-qualifiers (if any), ref-qualifier (if any), return type (if any), template-head, and trailing requires-clause ([dcl.decl]) (if any)

3.27[defns.signature.member.spec]signature

⟨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.28[defns.static.type]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.29[defns.unblock]unblock

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

3.30[defns.undefined]undefined behavior

behavior for which this document imposes no requirements
[Note
:
Undefined behavior may be expected when this document 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 in [intro] through [cpp] of this document ([expr.const]).
— end note
]

3.31[defns.unspecified]unspecified behavior

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 document.
— end note
]

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

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