1 General [intro]

1.3 Terms and definitions [intro.defs]

For the purposes of this document, the following definitions apply.

[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 International Standard are defined where they are used and italicized where they are defined.

1.3.1 argument [defns.argument]

actual argument
actual parameter
<function call expression> expression in the comma-separated list bounded by the parentheses

1.3.2 argument [defns.argument.macro]

actual argument
actual parameter
<function-like macro> sequence of preprocessing tokens in the comma-separated list bounded by the parentheses

1.3.3 argument [defns.argument.throw]

actual argument
actual parameter
<throw expression> the operand of throw

1.3.4 argument [defns.argument.templ]

actual argument
actual parameter
<template instantiation> expression, type-id or template-name in the comma-separated list bounded by the angle brackets

1.3.5 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 ]

1.3.6 diagnostic message [defns.diagnostic]

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

1.3.7 dynamic type [defns.dynamic.type]

<glvalue> type of the most derived object ([intro.object]) to which the glvalue denoted by a glvalue expression refers
Example: if a pointer ([dcl.ptr]) p whose static type is “pointer to class B” is pointing to an object of class D, derived from B (Clause [class.derived]), the dynamic type of the expression *p is “D.” References ([dcl.ref]) are treated similarly.  — end example ]

1.3.8 dynamic type [defns.dynamic.type.prvalue]

<prvalue> static type of the prvalue expression

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

program that is not well formed

1.3.10 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

1.3.11 implementation limits [defns.impl.limits]

restrictions imposed upon programs by the implementation

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

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

1.3.13 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 ]

1.3.14 parameter [defns.parameter]

formal argument
formal 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

1.3.15 parameter [defns.parameter.macro]

formal argument
formal parameter
<function-like macro> identifier from the comma-separated list bounded by the parentheses immediately following the macro name

1.3.16 parameter [defns.parameter.templ]

formal argument
formal parameter
<template> template-parameter

1.3.17 signature [defns.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 ]

1.3.18 signature [defns.signature.templ]

<function template> name, parameter type list ([dcl.fct]), enclosing namespace (if any), return type, and template parameter list

1.3.19 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)

1.3.20 signature [defns.signature.member]

<class member function> name, parameter type list ([dcl.fct]), class of which the function is a member, cv-qualifiers (if any), and ref-qualifier (if any)

1.3.21 signature [defns.signature.member.templ]

<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, and template parameter list

1.3.22 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)

1.3.23 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 ]

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

1.3.25 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 ]

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

C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Definition Rule ([basic.def.odr]).