For the purposes of this International Standard, the following definitions
apply. Other terms are defined
where they appear in italic type or on the left side of a syntax rule.
Terms explicitly defined in this
International Standard are not to be presumed to refer implicitly to
similar terms defined elsewhere. Terms
not defined in this International Standard are to be interpreted according
to ISO/IEC 2382.1. Mathematical
symbols not defined in this International Standard are to be interpreted
according to ISO 31.11.
Application . refers to an assembly that has an entry point (§10.1). When
an application is run, a new
application domain is created. Several different instantiations of an
application may exist on the same
machine at the same time, and each has its own application domain.
Application domain . an entity that enables application isolation by acting
as a container for application
state. An application domain acts as a container and boundary for the types
defined in the application and the
class libraries it uses. Types loaded into one application domain are
distinct from the same type loaded into
another application domain, and instances of objects are not directly
shared between application domains.
For instance, each application domain has its own copy of static variables
for these types, and a static
constructor for a type is run at most once per application domain.
Implementations are free to provide
implementation-specific policy or mechanisms for the creation and
destruction of application domains.
Argument . an expression in the comma-separated list bounded by the
parentheses in a method or instance
constructor call expression. It is also known as an actual argument.
Assembly . refers to one or more files that are output by the compiler as a
result of program compilation.
An assembly is a configured set of loadable code modules and other
resources that together implement a unit
of functionality. An assembly may contain types, the executable code used
to implement these types, and
references to other assemblies. The physical representation of an assembly
is not defined by this
specification. Essentially, an assembly is the output of the compiler.
Behavior . external appearance or action.
Behavior, implementation-defined . unspecified behavior where each
implementation documents how
the choice is made.
Behavior, undefined . behavior, upon use of a nonportable or erroneous
construct or of erroneous data,
for which this International Standard imposes no requirements. [Possible
handling of undefined behavior
ranges from ignoring the situation completely with unpredictable results,
to behaving during translation or
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)].
Behavior, unspecified . behavior where this International Standard provides
two or more possibilities and
imposes no further requirements on which is chosen in any instance.
Class library . refers to an assembly that can be used by other assemblies.
Use of a class library does not
cause the creation of a new application domain. Instead, a class library is
loaded into the application domain
that uses it. For instance, when an application uses a class library, that
class library is loaded into the
application domain for that application. If an application uses a class
library A that itself uses a class
library B, then both A and B are loaded into the application domain for the
application.
Diagnostic message . a message belonging to an implementation-defined
subset of the implementation.s
output messages.
Error, compile-time . an error reported during program translation.
Exception . an error condition that is outside the ordinary expected
behavior.