5.7)
Board'Last(2) -- upper bound of the second dimension of Board (see 3.\
6.1)
Board'Range(1) -- index range of the first dimension of Board (see 3.\
6.1)
Pool(K)'Terminated -- True if task Pool(K) is terminated (see 9.\
1)
Date'Size -- number of bits for records of type Date (see 3.\
8)
Message'Address -- address of the record variable Message (see 3.\
7.1)
4.2 Literals
1 A literal represents a value literally, that is, by means of notation
suited to its kind. A literal is either a numeric_literal, a character_
literal, the literal null, or a string_literal.
Name Resolution Rules
2 The expected type for a literal null shall be a single access type.
3 For a name that consists of a character_literal, either its expected type
shall be a single character type, in which case it is interpreted as a
parameterless function_call that yields the corresponding value of the
character type, or its expected profile shall correspond to a parameterless
function with a character result type, in which case it is interpreted as the
name of the corresponding parameterless function declared as part of the
character type's definition (see 3.5.1). In either case, the character_
literal denotes the enumeration_literal_specification.
4 The expected type for a primary that is a string_literal shall be a
single string type.
Legality Rules
5 A character_literal that is a name shall correspond to a defining_
character_literal of the expected type, or of the result type of the expected
profile.
6 For each character of a string_literal with a given expected string type,
there shall be a corresponding defining_character_literal of the component
type of the expected string type.
7 A literal null shall not be of an anonymous access type, since such types
do not have a null value (see 3.10).
Static Semantics
8 An integer literal is of type universal_integer. A real literal is of
type universal_real.
Dynamic Semantics
9 The evaluation of a numeric literal, or the literal null, yields the
represented value.
10 The evaluation of a string_literal that is a primary yields an array
value containing the value of each character of the sequence of characters of
the string_literal, as defined in 2.6. The bounds of this array value are
determined according to the rules for positional_array_aggregates (see
4.3.3), except that for a null string literal, the upper bound is the
predecessor of the lower bound.
11 For the evaluation of a string_literal of type T, a check is made that
the value of each character of the string_literal belongs to the component
subtype of T. For the evaluation of a null string literal, a check is made
that its lower bound is greater than the lower bound of the base range of the
index type. The exception Constraint_Error is raised if either of these
checks fails.
NOTES
12 (6) Enumeration literals that are identifiers rather than character_
literals follow the normal rules for identifiers when used in a name
(see 4.1 and 4.1.3). Character_literals used as selector_names follow
the normal rules for expanded names (see 4.1.3).
Examples
13 Examples of literals:
14
3.14159_26536 -- a real literal
1_345 -- an integer literal
'A' -- a character literal
"Some Text" -- a string literal
4.3 Aggregates
1 An aggregate combines component values into a composite value of an array
type, record type, or record extension.
Syntax
2 aggregate ::= record_aggregate | extension_aggregate | array_aggregate
Name Resolution Rules
3 The expected type for an aggregate shall be a single nonlimited array
type, record type, or record extension.
Legality Rules
4 An aggregate shall not be of a class-wide type.
Dynamic Semantics
5 For the evaluation of an aggregate, an anonymous object is created and
values for the components or ancestor part are obtained (as described in the
subsequent subclause for each kind of the aggregate) and assigned into the
corresponding components or ancestor part of the anonymous object. Obtaining
the values and the assignments occur in an arbitrary order. The value of the
aggregate is the value of this object.
6 If an aggregate is of a tagged type, a check is made that its value
belongs to the first subtype of the type. Constraint_Error is raised if this
check fails.
4.3.1 Record Aggregates
1 In a record_aggregate, a value is specified for each component of the
record or record extension value, using either a named or a positional
association.
Syntax
2 record_aggregate ::= (record_component_association_list)
3 record_component_association_list ::=
record_component_association {, record_component_association}
| null record
4 record_component_association ::=
[ component_choice_list => ] expression
5 component_choice_list ::=
component_selector_name {| component_selector_name}
| others
6 A record_component_association is a named component association if it
has a component_choice_list; otherwise, it is a positional component
association. Any positional component associations shall precede any
named component associations. If there is a named association with a
component_choice_list of others, it shall come last.
7 In the record_component_association_list for a record_aggregate, if
there is only one association, it shall be a named association.
Name Resolution Rules
8 The expected type for a record_aggregate shall be a single nonlimited
record type or record extension.
9 For the record_component_association_list of a record_aggregate, all
components of the composite value defined by the aggregate are needed; for
the association list of an extension_aggregate, only those components not
determined by the ancestor expression or subtype are needed (see 4.3.2).
Each selector_name in a record_component_association shall denote a needed
component (including possibly a discriminant).
10 The expected type for the expression of a record_component_association
is the type of the associated component(s); the associated component(s) are
as follows:
11 For a positional association, the component (including possibly a
discriminant) in the corresponding relative position (in the
declarative region of the type), counting only the needed
components;
12 For a named association with one or more component_selector_
names, the named component(s);
13 For a named association with the reserved word others, all needed
components that are not associated with some previous
association.
Legality Rules
14 If the type of a record_aggregate is a record extension, then it shall
be a descendant of a record type, through one or more record extensions (and
no private extensions).
15 If there are no components needed in a given record_component_
association_list, then the reserved words null record shall appear rather
than a list of record_component_associations.
16 Each record_component_association shall have at least one associated
component, and each needed component shall be associated with exactly one
record_component_association. If a record_component_association has two or
more associated components, all of them shall be of the same type.
17 If the components of a variant_part are needed, then the value of a
discriminant that governs the variant_part shall be given by a static
expression.
Dynamic Semantics
18 The evaluation of a record_aggregate consists of the evaluation of the
record_component_association_list.
19 For the evaluation of a record_component_association_list, any
per-object constraints (see 3.8) for components specified in the association
list are elaborated and any expressions are evaluated and converted to the
subtype of the associated component. Any constraint elaborations and
expression evaluations (and conversions) occur in an arbitrary order, except
that the expression for a discriminant is evaluated (and converted) prior to
the elaboration of any per-object constraint that depends on it, which in
turn occurs prior to the evaluation and conversion of the expression for the
component with the per-object constraint.
20 The expression of a record_component_association is evaluated (and
converted) once for each associated component.
NOTES
21 (7) For a record_aggregate with positional associations, expressions
specifying discriminant values appear first since the known_
discriminant_part is given first in the declaration of the type; they
have to be in the same order as in the known_discriminant_part.
Examples
22 Example of a record aggregate with positional associations:
23 (4, July, 1776) -- see 3.8
24 Examples of record aggregates with named associations:
25 (Day => 4, Month => July, Year => 1776)
(Month => July, Day => 4, Year => 1776)
26 (Disk, Closed, Track => 5, Cylinder => 12) -- see 3.8.1
(Unit => Disk, Status => Closed, Cylinder => 9, Track => 1)
27 Example of component association with several choices:
28 (Value => 0, Succ|Pred => new Cell'(0, null, null)) -- see 3.10.1
29 -- The allocator is evaluated twice: Succ and Pred designate different c\
ells
30 Examples of record aggregates for tagged types (see 3.9 and 3.9.1):
31 Expression'(null record)
Literal'(Value => 0.0)
Painted_Point'(0.0, Pi/2.0, Paint => Red)
4.3.2 Extension Aggregates
1 An extension_aggregate specifies a value for a type that is a record
extension by specifying a value or subtype for an ancestor of the type,
followed by associations for any components not determined by the ancestor_
part.
Syntax
2 extension_aggregate ::=
(ancestor_part with record_component_association_list)
3 ancestor_part ::= expression | subtype_mark
Name Resolution Rules
4 The expected type for an extension_aggregate shall be a single nonlimited
type that is a record extension. If the ancestor_part is an expression, it
is expected to be of any nonlimited tagged type.
Legality Rules
5 If the ancestor_part is a subtype_mark, it shall denote a specific tagged
subtype. The type of the extension_aggregate shall be derived from the type
of the ancestor_part, through one or more record extensions (and no private
extensions).
Static Semantics
6 For the record_component_association_list of an extension_aggregate, the
only components needed are those of the composite value defined by the
aggregate that are not inherited from the type of the ancestor_part, plus any
inherited discriminants if the ancestor_part is a subtype_mark that denotes
an unconstrained subtype.
Dynamic Semantics
7 For the evaluation of an extension_aggregate, the record_component_
association_list is evaluated. If the ancestor_part is an expression, it is
also evaluated; if the ancestor_part is a subtype_mark, the components of the
value of the aggregate not given by the record_component_association_list are
initialized by default as for an object of the ancestor type. Any implicit
initializations or evaluations are performed in an arbitrary order, except
that the expression for a discriminant is evaluated prior to any other
evaluation or initialization that depends on it.
8 If the type of the ancestor_part has discriminants that are not inherited
by the type of the extension_aggregate, then, unless the ancestor_part is a
subtype_mark that denotes an unconstrained subtype, a check is made that each
discriminant of the ancestor has the value specified for a corresponding
discriminant, either in the record_component_association_list, or in the
derived_type_definition for some ancestor of the type of the extension_
aggregate. Constraint_Error is raised if this check fails.
NOTES
9 (8) If all components of the value of the extension_aggregate are
determined by the ancestor_part, then the record_component_association_
list is required to be simply null record.
10 (9) If the ancestor_part is a subtype_mark, then its type can be
abstract. If its type is controlled, then as the last step of
evaluating the aggregate, the Initialize procedure of the ancestor type
is called, unless the Initialize procedure is abstract (see 7.6).
Examples
11 Examples of extension aggregates (for types defined in 3.9.1):
12 Painted_Point'(Point with Red)
(Point'(P) with Paint => Black)
13 (Expression with Left => 1.2, Right => 3.4)
Addition'(Binop with null record)
-- presuming Binop is of type Binary_Operation
4.3.3 Array Aggregates
1 In an array_aggregate, a value is specified for each component of an
array, either positionally or by its index. For a positional_array_
aggregate, the components are given in increasing-index order, with a final
others, if any, representing any remaining components. For a named_array_
aggregate, the components are identified by the values covered by the
discrete_choices.
Syntax
2 array_aggregate ::=
positional_array_aggregate | named_array_aggregate
3 positional_array_aggregate ::=
(expression, expression {, expression})
| (expression {, expression}, others => expression)
4 named_array_aggregate ::=
(array_component_association {, array_component_association})
5 array_component_association ::=
discrete_choice_list => expression
6 An n-dimensional array_aggregate is one that is written as n levels of
nested array_aggregates (or at the bottom level, equivalent string_literals).
For the multidimensional case (n >= 2) the array_aggregates (or equivalent
string_literals) at the n-1 lower levels are called subaggregates of the
enclosing n-dimensional array_aggregate. The expressions of the bottom level
subaggregates (or of the array_aggregate itself if one-dimensional) are
called the array component expressions of the enclosing n-dimensional array_
aggregate.
Name Resolution Rules
7 The expected type for an array_aggregate (that is not a subaggregate)
shall be a single nonlimited array type. The component type of this array
type is the expected type for each array component expression of the array_
aggregate.
8 The expected type for each discrete_choice in any discrete_choice_list of
a named_array_aggregate is the type of the corresponding index; the
corresponding index for an array_aggregate that is not a subaggregate is the
first index of its type; for an (n-m)-dimensional subaggregate within an
array_aggregate of an n-dimensional type, the corresponding index is the
index in position m+1.
Legality Rules
9 An array_aggregate of an n-dimensional array type shall be written as an
n-dimensional array_aggregate.
10 An others choice is allowed for an array_aggregate only if an applicable
index constraint applies to the array_aggregate. An applicable index
constraint is a constraint provided by certain contexts where an array_
aggregate is permitted that can be used to determine the bounds of the array
value specified by the aggregate. Each of the following contexts (and none
other) defines an applicable index constraint:
11 For an explicit_actual_parameter, an explicit_generic_actual_
parameter, the expression of a return_statement, the initializa-
tion expression in an object_declaration, or a default_expression
(for a parameter or a component), when the nominal subtype of the
corresponding formal parameter, generic formal parameter,
function result, object, or component is a constrained array
subtype, the applicable index constraint is the constraint of the
subtype;
12 For the expression of an assignment_statement where the name
denotes an array variable, the applicable index constraint is the
constraint of the array variable;
13 For the operand of a qualified_expression whose subtype_mark
denotes a constrained array subtype, the applicable index
constraint is the constraint of the subtype;
14 For a component expression in an aggregate, if the component's
nominal subtype is a constrained array subtype, the applicable
index constraint is the constraint of the subtype;
15 For a parenthesized expression, the applicable index constraint
is that, if any, defined for the expression.
16 The applicable index constraint applies to an array_aggregate that
appears in such a context, as well as to any subaggregates thereof. In the
case of an explicit_actual_parameter (or default_expression) for a call on a
generic formal subprogram, no applicable index constraint is defined.
17 The discrete_choice_list of an array_component_association is allowed to
have a discrete_choice that is a nonstatic expression or that is a discrete_
range that defines a nonstatic or null range, only if it is the single
discrete_choice of its discrete_choice_list, and there is only one array_
component_association in the array_aggregate.
18 In a named_array_aggregate with more than one discrete_choice, no two
discrete_choices are allowed to cover the same value (see 3.8.1); if there is
no others choice, the discrete_choices taken together shall exactly cover a
contiguous sequence of values of the corresponding index type.
19 A bottom level subaggregate of a multidimensional array_aggregate of a
given array type is allowed to be a string_literal only if the component type
of the array type is a character type; each character of such a string_
literal shall correspond to a defining_character_literal of the component
type.
Static Semantics
20 A subaggregate that is a string_literal is equivalent to one that is a
positional_array_aggregate of the same length, with each expression being the
character_literal for the corresponding character of the string_literal.
Dynamic Semantics
21 The evaluation of an array_aggregate of a given array type proceeds in
two steps:
22 Any discrete_choices of this aggregate and of its subaggregates
are evaluated in an arbitrary order, and converted to the
corresponding index type;
23 The array component expressions of the aggregate are evaluated in
an arbitrary order and their values are converted to the
component subtype of the array type; an array component
expression is evaluated once for each associated component.
24 The bounds of the index range of an array_aggregate (including a
subaggregate) are determined as follows:
25 For an array_aggregate with an others choice, the bounds are
those of the corresponding index range from the applicable index
constraint;
26 For a positional_array_aggregate (or equivalent string_literal)
without an others choice, the lower bound is that of the
corresponding index range in the applicable index constraint, if
defined, or that of the corresponding index subtype, if not; in
either case, the upper bound is determined from the lower bound
and the number of expressions (or the length of the string_
literal);
27 For a named_array_aggregate without an others choice, the bounds
are determined by the smallest and largest index values covered
by any discrete_choice_list.
28 For an array_aggregate, a check is made that the index range defined by
its bounds is compatible with the corresponding index subtype.
29 For an array_aggregate with an others choice, a check is made that no
expression is specified for an index value outside the bounds determined by
the applicable index constraint.
30 For a multidimensional array_aggregate, a check is made that all
subaggregates that correspond to the same index have the same bounds.
31 The exception Constraint_Error is raised if any of the above checks
fail.
NOTES
32 (10) In an array_aggregate, positional notation may only be used with
two or more expressions; a single expression in parentheses is
interpreted as a parenthesized_expression. A named_array_aggregate,
such as (1 => X), may be used to specify an array with a single
component.
Examples
33 Examples of array aggregates with positional associations:
34 (7, 9, 5, 1, 3, 2, 4, 8, 6, 0)
Table'(5, 8, 4, 1, others => 0) -- see 3.6
35 Examples of array aggregates with named associations:
36 (1 .. 5 => (1 .. 8 => 0.0)) -- two-dimensional
(1 .. N => new Cell) -- N new cells, in particular for N = 0
37 Table'(2 | 4 | 10 => 1, others => 0)
Schedule'(Mon .. Fri => True, others => False) -- see 3.6
Schedule'(Wed | Sun => False, others => True)
Vector'(1 => 2.5) -- single-component vector
38 Examples of two-dimensional array aggregates:
39 -- Three aggregates for the same value of subtype Matrix(1..2,1..3) (see 3.\
6):
40 ((1.1, 1.2, 1.3), (2.1, 2.2, 2.3))
(1 => (1.1, 1.2, 1.3), 2 => (2.1, 2.2, 2.3))
(1 => (1 => 1.1, 2 => 1.2, 3 => 1.3), 2 => (1 => 2.1, 2 => 2.2, 3 => 2.3))
41 Examples of aggregates as initial values:
42 A : Table := (7, 9, 5, 1, 3, 2, 4, 8, 6, 0); -- A(1)=7, A(10)=0
B : Table := (2 | 4 | 10 => 1, others => 0); -- B(1)=0, B(10)=1
C : constant Matrix := (1 .. 5 => (1 .. 8 => 0.0)); -- C'Last(1)=5, C'Last(\
2)=8
43 D : Bit_Vector(M .. N) := (M .. N => True); -- see 3.6
E : Bit_Vector(M .. N) := (others => True);
F : String(1 .. 1) := (1 => 'F'); -- a one component aggregate: same as "F"
4.4 Expressions
1 An expression is a formula that defines the computation or retrieval of a
value. In this International Standard, the term ``expression'' refers to a
construct of the syntactic category expression or of any of the other five
syntactic categories defined below.
Syntax
2 expression ::=
relation {and relation} | relation {and then relation}
| relation {or relation} | relation {or else relation}
| relation {xor relation}
3 relation ::=
simple_expression [relational_operator simple_expression]
| simple_expression [not] in range
| simple_expression [not] in subtype_mark
4 simple_expression ::= [unary_adding_operator] term {binary_adding_operator \
term}
5 term ::= factor {multiplying_operator factor}
6 factor ::= primary [** primary] | abs primary | not primary
7 primary ::=
numeric_literal | null | string_literal | aggregate
| name | qualified_expression | allocator | (expression)
Name Resolution Rules
8 A name used as a primary shall resolve to denote an object or a value.
Static Semantics
9 Each expression has a type; it specifies the computation or retrieval of
a value of that type.
Dynamic Semantics
10 The value of a primary that is a name denoting an object is the value of
the object.
Implementation Permissions
11 For the evaluation of a primary that is a name denoting an object of an
unconstrained numeric subtype, if the value of the object is outside the base
range of its type, the implementation may either raise Constraint_Error or
return the value of the object.
Examples
12 Examples of primaries:
13 4.0 -- real literal
Pi -- named number
(1 .. 10 => 0) -- array aggregate
Sum -- variable
Integer'Last -- attribute
Sine(X) -- function call
Color'(Blue) -- qualified expression
Real(M*N) -- conversion
(Line_Count + 10) -- parenthesized expression
14 Examples of expressions:
15 Volume -- primary
not Destroyed -- factor
2*Line_Count -- term
-4.0 -- simple expression
-4.0 + A -- simple expression
B**2 - 4.0*A*C -- simple expression
Password(1 .. 3) = "Bwv" -- relation
Count in Small_Int -- relation
Count not in Small_Int -- relation
Index = 0 or Item_Hit -- expression
(Cold and Sunny) or Warm -- expression (parentheses are required)
A**(B**C) -- expression (parentheses are required)
4.5 Operators and Expression Evaluation
1 The language defines the following six categories of operators (given in
order of increasing precedence). The corresponding operator_symbols, and
only those, can be used as designators in declarations of functions for
user-defined operators. See 6.6, ``Overloading of Operators''.
Syntax
2 logical_operator ::= and | or | xor
3 relational_operator ::= = | /= | < \
| <= | > | >=
4 binary_adding_operator ::= + | - | &
5 unary_adding_operator ::= + | -
6 multiplying_operator ::= * | / | mod \
| rem
7 highest_precedence_operator ::= ** | abs | not
Static Semantics
8 For a sequence of operators of the same precedence level, the operators
are associated with their operands in textual order from left to right.
Parentheses can be used to impose specific associations.
9 For each form of type definition, certain of the above operators are
predefined; that is, they are implicitly declared immediately after the type
definition. For each such implicit operator declaration, the parameters are
called Left and Right for binary operators; the single parameter is called
Right for unary operators. An expression of the form X op Y, where op is a
binary operator, is equivalent to a function_call of the form "op"(X, Y). An
expression of the form op Y, where op is a unary operator, is equivalent to a
function_call of the form "op"(Y). The predefined operators and their
effects are described in subclauses 4.5.1 through 4.5.6.
Dynamic Semantics
10 The predefined operations on integer types either yield the
mathematically correct result or raise the exception Constraint_Error. For
implementations that support the Numerics Annex, the predefined operations on
real types yield results whose accuracy is defined in Annex G, or raise the
exception Constraint_Error.
Implementation Requirements
11 The implementation of a predefined operator that delivers a result of an
integer or fixed point type may raise Constraint_Error only if the result is
outside the base range of the result type.
12 The implementation of a predefined operator that delivers a result of a
floating point type may raise Constraint_Error only if the result is outside
the safe range of the result type.
Implementation Permissions
13 For a sequence of predefined operators of the same precedence level (and
in the absence of parentheses imposing a specific association), an
implementation may impose any association of the operators with operands so
long as the result produced is an allowed result for the left-to-right
association, but ignoring the potential for failure of language-defined
checks in either the left-to-right or chosen order of association.
NOTES
14 (11) The two operands of an expression of the form X op Y, where op is a
binary operator, are evaluated in an arbitrary order, as for any
function_call (see 6.4).
Examples
15 Examples of precedence:
16 not Sunny or Warm -- same as (not Sunny) or Warm
X > 4.0 and Y > 0.0 -- same as (X > 4.0) and (Y > 0.0)
17 -4.0*A**2 -- same as -(4.0 * (A**2))
abs(1 + A) + B -- same as (abs (1 + A)) + B
Y**(-3) -- parentheses are necessary
A / B * C -- same as (A/B)*C
A + (B + C) -- evaluate B + C before adding it to A
4.5.1 Logical Operators and Short-circuit Control Forms
Name Resolution Rules
1 An expression consisting of two relations connected by and then or or
else (a short-circuit control form) shall resolve to be of some boolean type;
the expected type for both relations is that same boolean type.
Static Semantics
2 The following logical operators are predefined for every boolean type T,
for every modular type T, and for every one-dimensional array type T whose
component type is a boolean type:
3
function "and"(Left, Right : T) return T
function "or" (Left, Right : T) return T
function "xor"(Left, Right : T) return T
4 For boolean types, the predefined logical operators and, or, and xor
perform the conventional operations of conjunction, inclusive disjunction,
and exclusive disjunction, respectively.
5 For modular types, the predefined logical operators are defined on a
bit-by-bit basis, using the binary representation of the value of the
operands to yield a binary representation for the result, where zero
represents False and one represents True. If this result is outside the base
range of the type, a final subtraction by the modulus is performed to bring
the result into the base range of the type.
6 The logical operators on arrays are performed on a component-by-component
basis on matching components (as for equality -- see 4.5.2), using the
predefined logical operator for the component type. The bounds of the
resulting array are those of the left operand.
Dynamic Semantics
7 The short-circuit control forms and then and or else deliver the same
result as the corresponding predefined and and or operators for boolean
types, except that the left operand is always evaluated first, and the right
operand is not evaluated if the value of the left operand determines the
result.
8 For the logical operators on arrays, a check is made that for each
component of the left operand there is a matching component of the right
operand, and vice versa. Also, a check is made that each component of the
result belongs to the component subtype. The exception Constraint_Error is
raised if either of the above checks fails.
NOTES
9 (12) The conventional meaning of the logical operators is given by the
following truth table:
10
A B (A and B) (A or B) (A \
xor B)
True True True True \
False
True False False True \
True
False True False True \
True
False False False False \
False
Examples
11 Examples of logical operators:
12 Sunny or Warm
Filter(1 .. 10) and Filter(15 .. 24) -- see 3.6.1
13 Examples of short-circuit control forms:
14 Next_Car.Owner /= null and then Next_Car.Owner.Age > 25 -- see 3.10.1
N = 0 or else A(N) = Hit_Value
4.5.2 Relational Operators and Membership Tests
1 The equality operators = (equals) and /= (not equals) are predefined for
nonlimited types. The other relational_operators are the ordering operators
< (less than), <= (less than or equal), > (greater than), and >= (greater
than or equal). The ordering operators are predefined for scalar types, and
for discrete array types, that is, one-dimensional array types whose
components are of a discrete type.
2 A membership test, using in or not in, determines whether or not a value
belongs to a given subtype or range, or has a tag that identifies a type that
is covered by a given type. Membership tests are allowed for all types.
Name Resolution Rules
3 The tested type of a membership test is the type of the range or the type
determined by the subtype_mark. If the tested type is tagged, then the
simple_expression shall resolve to be of a type that covers or is covered by
the tested type; if untagged, the expected type for the simple_expression is
the tested type.
Legality Rules
4 For a membership test, if the simple_expression is of a tagged class-wide
type, then the tested type shall be (visibly) tagged.
Static Semantics
5 The result type of a membership test is the predefined type Boolean.
6 The equality operators are predefined for every specific type T that is
not limited, and not an anonymous access type, with the following
specifications:
7 function "=" (Left, Right : T) return Boolean
function "/="(Left, Right : T) return Boolean
8 The ordering operators are predefined for every specific scalar type T,
and for every discrete array type T, with the following specifications:
9 function "<" (Left, Right : T) return Boolean
function "<="(Left, Right : T) return Boolean
function ">" (Left, Right : T) return Boolean
function ">="(Left, Right : T) return Boolean
Dynamic Semantics
10 For discrete types, the predefined relational operators are defined in
terms of corresponding mathematical operations on the position numbers of the
values of the operands.
11 For real types, the predefined relational operators are defined in terms
of the corresponding mathematical operations on the values of the operands,
subject to the accuracy of the type.
12 Two access-to-object values are equal if they designate the same object,
or if both are equal to the null value of the access type.
13 Two access-to-subprogram values are equal if they are the result of the
same evaluation of an Access attribute_reference, or if both are equal to the
null value of the access type. Two access-to-subprogram values are unequal
if they designate different subprograms. It is unspecified whether two
access values that designate the same subprogram but are the result of
distinct evaluations of Access attribute_references are equal or unequal.
14 For a type extension, predefined equality is defined in terms of the
primitive (possibly user-defined) equals operator of the parent type and of
any tagged components of the extension part, and predefined equality for any
other components not inherited from the parent type.
15 For a private type, if its full type is tagged, predefined equality is
defined in terms of the primitive equals operator of the full type; if the
full type is untagged, predefined equality for the private type is that of
its full type.
16 For other composite types, the predefined equality operators (and
certain other predefined operations on composite types -- see 4.5.1 and 4.6)
are defined in terms of the corresponding operation on matching components,
defined as follows:
17 For two composite objects or values of the same non-array type,
matching components are those that correspond to the same
component_declaration or discriminant_specification;
18 For two one-dimensional arrays of the same type, matching
components are those (if any) whose index values match in the
following sense: the lower bounds of the index ranges are defined
to match, and the successors of matching indices are defined to
match;
19 For two multidimensional arrays of the same type, matching
components are those whose index values match in successive index
positions.
20 The analogous definitions apply if the types of the two objects or
values are convertible, rather than being the same.
21 Given the above definition of matching components, the result of the
predefined equals operator for composite types (other than for those
composite types covered earlier) is defined as follows:
22 If there are no components, the result is defined to be True;
23 If there are unmatched components, the result is defined to be
False;
24 Otherwise, the result is defined in terms of the primitive equals
operator for any matching tagged components, and the predefined
equals for any matching untagged components.
25 The predefined "/=" operator gives the complementary result to the
predefined "=" operator.
26 For a discrete array type, the predefined ordering operators correspond
to lexicographic order using the predefined order relation of the component
type: A null array is lexicographically less than any array having at least
one component. In the case of nonnull arrays, the left operand is
lexicographically less than the right operand if the first component of the
left operand is less than that of the right; otherwise the left operand is
lexicographically less than the right operand only if their first components
are equal and the tail of the left operand is lexicographically less than
that of the right (the tail consists of the remaining components beyond the
first and can be null).
27 For the evaluation of a membership test, the simple_expression and the
range (if any) are evaluated in an arbitrary order.
28 A membership test using in yields the result True if:
29 The tested type is scalar, and the value of the simple_expression
belongs to the given range, or the range of the named subtype; or
30 The tested type is not scalar, and the value of the simple_
expression satisfies any constraints of the named subtype, and,
if the type of the simple_expression is class-wide, the value has
a tag that identifies a type covered by the tested type.
31 Otherwise the test yields the result False.
32 A membership test using not in gives the complementary result to the
corresponding membership test using in.
NOTES
33 (13) No exception is ever raised by a membership test, by a predefined
ordering operator, or by a predefined equality operator for an
elementary type, but an exception can be raised by the evaluation of the
operands. A predefined equality operator for a composite type can only
raise an exception if the type has a tagged part whose primitive equals
operator propagates an exception.
34 (14) If a composite type has components that depend on discriminants,
two values of this type have matching components if and only if their
discriminants are equal. Two nonnull arrays have matching components if
and only if the length of each dimension is the same for both.
Examples
35 Examples of expressions involving relational operators and membership
tests:
36 X /= Y
37 "" < "A" and "A" < "Aa" -- True
"Aa" < "B" and "A" < "A " -- True
38 My_Car = null -- true if My_Car has been set to null (see 3.1\
0.1)
My_Car = Your_Car -- true if we both share the same car
My_Car.all = Your_Car.all -- true if the two cars are identical
39 N not in 1 .. 10 -- range membership test
Today in Mon .. Fri -- range membership test
Today in Weekday -- subtype membership test (see 3.5.1)
Archive in Disk_Unit -- subtype membership test (see 3.8.1)
Tree.all in Addition'Class -- class membership test (see 3.9.1)
4.5.3 Binary Adding Operators
Static Semantics
1 The binary adding operators + (addition) and - (subtraction) are
predefined for every specific numeric type T with their conventional meaning.
They have the following specifications:
2 function "+"(Left, Right : T) return T
function "-"(Left, Right : T) return T
3 The concatenation operators & are predefined for every nonlimited,
one-dimensional array type T with component type C. They have the following
specifications:
4 function "&"(Left : T; Right : T) return T
function "&"(Left : T; Right : C) return T
function "&"(Left : C; Right : T) return T
function "&"(Left : C; Right : C) return T
Dynamic Semantics
5 For the evaluation of a concatenation with result type T, if both
operands are of type T, the result of the concatenation is a one-dimensional
array whose length is the sum of the lengths of its operands, and whose
components comprise the components of the left operand followed by the
components of the right operand. If the left operand is a null array, the
result of the concatenation is the right operand. Otherwise, the lower bound
of the result is determined as follows:
6 If the ultimate ancestor of the array type was defined by a
constrained_array_definition, then the lower bound of the result
is that of the index subtype;
7 If the ultimate ancestor of the array type was defined by an
unconstrained_array_definition, then the lower bound of the
result is that of the left operand.
8 The upper bound is determined by the lower bound and the length. A check
is made that the upper bound of the result of the concatenation belongs to
the range of the index subtype, unless the result is a null array.
Constraint_Error is raised if this check fails.
9 If either operand is of the component type C, the result of the
concatenation is given by the above rules, using in place of such an operand
an array having this operand as its only component (converted to the
component subtype) and having the lower bound of the index subtype of the
array type as its lower bound.
10 The result of a concatenation is defined in terms of an assignment to an
anonymous object, as for any function call (see 6.5).
NOTES
11 (15) As for all predefined operators on modular types, the binary adding
operators + and - on modular types include a final reduction modulo the
modulus if the result is outside the base range of the type.
Examples
12 Examples of expressions involving binary adding operators:
13 Z + 0.1 -- Z has to be of a real type
14 "A" & "BCD" -- concatenation of two string literals
'A' & "BCD" -- concatenation of a character literal and a string literal
'A' & 'A' -- concatenation of two character literals
4.5.4 Unary Adding Operators
Static Semantics
1 The unary adding operators + (identity) and - (negation) are predefined
for every specific numeric type T with their conventional meaning. They have
the following specifications:
2 function "+"(Right : T) return T
function "-"(Right : T) return T
NOTES
3 (16) For modular integer types, the unary adding operator -, when given
a nonzero operand, returns the result of subtracting the value of the
operand from the modulus; for a zero operand, the result is zero.
4.5.5 Multiplying Operators
Static Semantics
1 The multiplying operators * (multiplication), / (division), mod
(modulus), and rem (remainder) are predefined for every specific integer type
T:
2 function "*" (Left, Right : T) return T
function "/" (Left, Right : T) return T
function "mod"(Left, Right : T) return T
function "rem"(Left, Right : T) return T
3 Signed integer multiplication has its conventional meaning.
4 Signed integer division and remainder are defined by the relation:
5 A = (A/B)*B + (A rem B)
6 where (A rem B) has the sign of A and an absolute value less than the
absolute value of B. Signed integer division satisfies the identity:
7 (-A)/B = -(A/B) = A/(-B)
8 The signed integer modulus operator is defined such that the result of A
mod B has the sign of B and an absolute value less than the absolute value of
B; in addition, for some signed integer value N, this result satisfies the
relation:
9 A = B*N + (A mod B)
10 The multiplying operators on modular types are defined in terms of the
corresponding signed integer operators, followed by a reduction modulo the
modulus if the result is outside the base range of the type (which is only
possible for the "*" operator).
11 Multiplication and division operators are predefined for every specific
floating point type T:
12 function "*"(Left, Right : T) return T
function "/"(Left, Right : T) return T
13 The following multiplication and division operators, with an operand of
the predefined type Integer, are predefined for every specific fixed point
type T:
14 function "*"(Left : T; Right : Integer) return T
function "*"(Left : Integer; Right : T) return T
function "/"(Left : T; Right : Integer) return T
15 All of the above multiplying operators are usable with an operand of an
appropriate universal numeric type. The following additional multiplying
operators for root_real are predefined, and are usable when both operands are
of an appropriate universal or root numeric type, and the result is allowed
to be of type root_real, as in a number_declaration:
16 function "*"(Left, Right : root_real) return root_real
function "/"(Left, Right : root_real) return root_real
17 function "*"(Left : root_real; Right : root_integer) return root_real
function "*"(Left : root_integer; Right : root_real) return root_real
function "/"(Left : root_real; Right : root_integer) return root_real
18 Multiplication and division between any two fixed point types are
provided by the following two predefined operators:
19 function "*"(Left, Right : universal_fixed) return universal_fixed
function "/"(Left, Right : universal_fixed) return universal_fixed
Legality Rules
20 The above two fixed-fixed multiplying operators shall not be used in a
context where the expected type for the result is itself universal_fixed --
the context has to identify some other numeric type to which the result is to
be converted, either explicitly or implicitly.
Dynamic Semantics
21 The multiplication and division operators for real types have their
conventional meaning. For floating point types, the accuracy of the result
is determined by the precision of the result type. For decimal fixed point
types, the result is truncated toward zero if the mathematical result is
between two multiples of the small of the specific result type (possibly
determined by context); for ordinary fixed point types, if the mathematical
result is between two multiples of the small, it is unspecified which of the
two is the result.
22 The exception Constraint_Error is raised by integer division, rem, and
mod if the right operand is zero. Similarly, for a real type T with
T'Machine_Overflows True, division by zero raises Constraint_Error.
NOTES
23 (17) For positive A and B, A/B is the quotient and A rem B is the
remainder when A is divided by B. The following relations are satisfied
by the rem operator:
24 A rem (-B) = A rem B
(-A) rem B = -(A rem B)
25 (18) For any signed integer K, the following identity holds:
26 A mod B = (A + K*B) mod B
27The relations between signed integer division, remainder, and
modulus are illustrated by the following table:
28 A B A/B A rem B A mod B A B A/B A rem B A mod\
B
29 10 5 2 0 0 -10 5 -2 0 0
11 5 2 1 1 -11 5 -2 -1 4
12 5 2 2 2 -12 5 -2 -2 3
13 5 2 3 3 -13 5 -2 -3 2
14 5 2 4 4 -14 5 -2 -4 1
30 A B A/B A rem B A mod B A B A/B A rem B A mod\
B
10 -5 -2 0 0 -10 -5 2 0 0
11 -5 -2 1 -4 -11 -5 2 -1 -1
12 -5 -2 2 -3 -12 -5 2 -2 -2
13 -5 -2 3 -2 -13 -5 2 -3 -3
14 -5 -2 4 -1 -14 -5 2 -4 -4
Examples
31 Examples of expressions involving multiplying operators:
32 I : Integer := 1;
J : Integer := 2;
K : Integer := 3;
33 X : Real := 1.0; -- see 3.5.7
Y : Real := 2.0;
34 F : Fraction := 0.25; -- see 3.5.9
G : Fraction := 0.5;
35
Expression Value Result Type
I*J 2 same as I and J, that is, Integer
K/J 1 same as K and J, that is, Integer
K mod J 1 same as K and J, that is, Integer
X/Y 0.5 same as X and Y, that is, Real
F/2 0.125 same as F, that is, Fraction
3*F 0.75 same as F, that is, Fraction
0.75*G 0.375 universal_fixed, implicitly conve\
rtible
to any fixed point type
Fraction(F*G) 0.125 Fraction, as stated by the conver\
sion
Real(J)*Y 4.0 Real, the type of both operands a\
fter
conversion of J
4.5.6 Highest Precedence Operators
Static Semantics
1 The highest precedence unary operator abs (absolute value) is predefined
for every specific numeric type T, with the following specification:
2 function "abs"(Right : T) return T
3 The highest precedence unary operator not (logical negation) is
predefined for every boolean type T, every modular type T, and for every
one-dimensional array type T whose components are of a boolean type, with the
following specification:
4 function "not"(Right : T) return T
5 The result of the operator not for a modular type is defined as the
difference between the high bound of the base range of the type and the value
of the operand. For a binary modulus, this corresponds to a bit-wise
complement of the binary representation of the value of the operand.
6 The operator not that applies to a one-dimensional array of boolean
components yields a one-dimensional boolean array with the same bounds; each
component of the result is obtained by logical negation of the corresponding
component of the operand (that is, the component that has the same index
value). A check is made that each component of the result belongs to the
component subtype; the exception Constraint_Error is raised if this check
fails.
7 The highest precedence exponentiation operator ** is predefined for every
specific integer type T with the following specification:
8 function "**"(Left : T; Right : Natural) return T
9 Exponentiation is also predefined for every specific floating point type
as well as root_real, with the following specification (where T is root_real
or the floating point type):
10 function "**"(Left : T; Right : Integer'Base) return T
11 The right operand of an exponentiation is the exponent. The expression
X**N with the value of the exponent N positive is equivalent to the
expression X*X*...X (with N-1 multiplications) except that the multiplica-
tions are associated in an arbitrary order. With N equal to zero, the result
is one. With the value of N negative (only defined for a floating point
operand), the result is the reciprocal of the result using the absolute value
of N as the exponent.
Implementation Permissions
12 The implementation of exponentiation for the case of a negative exponent
is allowed to raise Constraint_Error if the intermediate result of the
repeated multiplications is outside the safe range of the type, even though
the final result (after taking the reciprocal) would not be. (The best
machine approximation to the final result in this case would generally be
0.0.)
NOTES
13 (19) As implied by the specification given above for exponentiation of
an integer type, a check is made that the exponent is not negative.
Constraint_Error is raised if this check fails.
4.6 Type Conversions
1 Explicit type conversions, both value conversions and view conversions,
are allowed between closely related types as defined below. This clause also
defines rules for value and view conversions to a particular subtype of a
type, both explicit ones and those implicit in other constructs.
Syntax
2 type_conversion ::=
subtype_mark(expression)
| subtype_mark(name)
3 The target subtype of a type_conversion is the subtype denoted by the
subtype_mark. The operand of a type_conversion is the expression or name
within the parentheses; its type is the operand type.
4 One type is convertible to a second type if a type_conversion with the
first type as operand type and the second type as target type is legal
according to the rules of this clause. Two types are convertible if each is
convertible to the other.
5 A type_conversion whose operand is the name of an object is called a view
conversion if its target type is tagged, or if it appears as an actual
parameter of mode out or in out; other type_conversions are called value
conversions.
Name Resolution Rules
6 The operand of a type_conversion is expected to be of any type.
7 The operand of a view conversion is interpreted only as a name; the
operand of a value conversion is interpreted as an expression.
Legality Rules
8 If the target type is a numeric type, then the operand type shall be a
numeric type.
9 If the target type is an array type, then the operand type shall be an
array type. Further:
10 The types shall have the same dimensionality;
11 Corresponding index types shall be convertible; and
12 The component subtypes shall statically match.
13 If the target type is a general access type, then the operand type shall
be an access-to-object type. Further:
14 If the target type is an access-to-variable type, then the
operand type shall be an access-to-variable type;
15 If the target designated type is tagged, then the operand
designated type shall be convertible to the target designated
type;
16 If the target designated type is not tagged, then the designated
types shall be the same, and either the designated subtypes shall
statically match or the target designated subtype shall be
discriminated and unconstrained; and
17 The accessibility level of the operand type shall not be
statically deeper than that of the target type. In addition to
the places where Legality Rules normally apply (see 12.3), this
rule applies also in the private part of an instance of a generic
unit.
18 If the target type is an access-to-subprogram type, then the operand
type shall be an access-to-subprogram type. Further:
19 The designated profiles shall be subtype-conformant.
20 The accessibility level of the operand type shall not be
statically deeper than that of the target type. In addition to
the places where Legality Rules normally apply (see 12.3), this
rule applies also in the private part of an instance of a generic
unit. If the operand type is declared within a generic body, the
target type shall be declared within the generic body.
21 If the target type is not included in any of the above four cases, there
shall be a type that is an ancestor of both the target type and the operand
type. Further, if the target type is tagged, then either:
22 The operand type shall be covered by or descended from the target
type; or
23 The operand type shall be a class-wide type that covers the
target type.
24 In a view conversion for an untagged type, the target type shall be
convertible (back) to the operand type.
Static Semantics
25 A type_conversion that is a value conversion denotes the value that is
the result of converting the value of the operand to the target subtype.
26 A type_conversion that is a view conversion denotes a view of the object
denoted by the operand. This view is a variable of the target type if the
operand denotes a variable; otherwise it is a constant of the target type.
27 The nominal subtype of a type_conversion is its target subtype.
Dynamic Semantics
28 For the evaluation of a type_conversion that is a value conversion, the
operand is evaluated, and then the value of the operand is converted to a
corresponding value of the target type, if any. If there is no value of the
target type that corresponds to the operand value, Constraint_Error is
raised; this can only happen on conversion to a modular type, and only when
the operand value is outside the base range of the modular type. Additional
rules follow:
29 Numeric Type Conversion
30 If the target and the operand types are both integer
types, then the result is the value of the target type
that corresponds to the same mathematical integer as the
operand.
31 If the target type is a decimal fixed point type, then the
result is truncated (toward 0) if the value of the operand
is not a multiple of the small of the target type.
32 If the target type is some other real type, then the
result is within the accuracy of the target type (see G.2,
``Numeric Performance Requirements'', for implementations
that support the Numerics Annex).
33 If the target type is an integer type and the operand type
is real, the result is rounded to the nearest integer
(away from zero if exactly halfway between two integers).
34 Enumeration Type Conversion
35 The result is the value of the target type with the same
position number as that of the operand value.
36 Array Type Conversion
37 If the target subtype is a constrained array subtype, then
a check is made that the length of each dimension of the
value of the operand equals the length of the
corresponding dimension of the target subtype. The bounds
of the result are those of the target subtype.
38 If the target subtype is an unconstrained array subtype,
then the bounds of the result are obtained by converting
each bound of the value of the operand to the
corresponding index type of the target type. For each
nonnull index range, a check is made that the bounds of
the range belong to the corresponding index subtype.
39 In either array case, the value of each component of the
result is that of the matching component of the operand
value (see 4.5.2).
40 Composite (Non-Array) Type Conversion
41 The value of each nondiscriminant component of the result
is that of the matching component of the operand value.
42 The tag of the result is that of the operand. If the
operand type is class-wide, a check is made that the tag
of the operand identifies a (specific) type that is
covered by or descended from the target type.
43 For each discriminant of the target type that corresponds
to a discriminant of the operand type, its value is that
of the corresponding discriminant of the operand value;
if it corresponds to more than one discriminant of the
operand type, a check is made that all these discriminants
are equal in the operand value.
44 For each discriminant of the target type that corresponds
to a discriminant that is specified by the derived_type_
definition for some ancestor of the operand type (or if
class-wide, some ancestor of the specific type identified
by the tag of the operand), its value in the result is
that specified by the derived_type_definition.
45 For each discriminant of the operand type that corresponds
to a discriminant that is specified by the derived_type_
definition for some ancestor of the target type, a check
is made that in the operand value it equals the value
specified for it.
46 For each discriminant of the result, a check is made that
its value belongs to its subtype.
47 Access Type Conversion
48 For an access-to-object type, a check is made that the
accessibility level of the operand type is not deeper than
that of the target type.
49 If the target type is an anonymous access type, a check is
made that the value of the operand is not null; if the
target is not an anonymous access type, then the result is
null if the operand value is null.
50 If the operand value is not null, then the result
designates the same object (or subprogram) as is
designated by the operand value, but viewed as being of
the target designated subtype (or profile); any checks
associated with evaluating a conversion to the target
designated subtype are performed.
51 After conversion of the value to the target type, if the target subtype
is constrained, a check is performed that the value satisfies this
constraint.
52 For the evaluation of a view conversion, the operand name is evaluated,
and a new view of the object denoted by the operand is created, whose type is
the target type; if the target type is composite, checks are performed as
above for a value conversion.
53 The properties of this new view are as follows:
54 If the target type is composite, the bounds or discriminants (if
any) of the view are as defined above for a value conversion;
each nondiscriminant component of the view denotes the matching
component of the operand object; the subtype of the view is
constrained if either the target subtype or the operand object is
constrained, or if the operand type is a descendant of the target
type, and has discriminants that were not inherited from the
target type;
55 If the target type is tagged, then an assignment to the view
assigns to the corresponding part of the object denoted by the
operand; otherwise, an assignment to the view assigns to the
object, after converting the assigned value to the subtype of the
object (which might raise Constraint_Error);
56 Reading the value of the view yields the result of converting the
value of the operand object to the target subtype (which might
raise Constraint_Error), except if the object is of an access
type and the view conversion is passed as an out parameter; in
this latter case, the value of the operand object is used to
initialize the formal parameter without checking against any
constraint of the target subtype (see 6.4.1).
57 If an Accessibility_Check fails, Program_Error is raised. Any other
check associated with a conversion raises Constraint_Error if it fails.
58 Conversion to a type is the same as conversion to an unconstrained
subtype of the type.
NOTES
59 (20) In addition to explicit type_conversions, type conversions are
performed implicitly in situations where the expected type and the
actual type of a construct differ, as is permitted by the type
resolution rules (see 8.6). For example, an integer literal is of the
type universal_integer, and is implicitly converted when assigned to a
target of some specific integer type. Similarly, an actual parameter of
a specific tagged type is implicitly converted when the corresponding
formal parameter is of a class-wide type.
60 Even when the expected and actual types are the same, implicit
subtype conversions are performed to adjust the array bounds (if any) of
an operand to match the desired target subtype, or to raise Constraint_
Error if the (possibly adjusted) value does not satisfy the constraints
of the target subtype.
61 (21) A ramification of the overload resolution rules is that the operand
of an (explicit) type_conversion cannot be the literal null, an
allocator, an aggregate, a string_literal, a character_literal, or an
attribute_reference for an Access or Unchecked_Access attribute.
Similarly, such an expression enclosed by parentheses is not allowed. A
qualified_expression (see 4.7) can be used instead of such a type_
conversion.
62 (22) The constraint of the target subtype has no effect for a type_
conversion of an elementary type passed as an out parameter. Hence, it
is recommended that the first subtype be specified as the target to
minimize confusion (a similar recommendation applies to renaming and
generic formal in out objects).
Examples
63 Examples of numeric type conversion:
64 Real(2*J) -- value is converted to floating point
Integer(1.6) -- value is 2
Integer(-0.4) -- value is 0
65 Example of conversion between derived types:
66 type A_Form is new B_Form;
67 X : A_Form;
Y : B_Form;
68 X := A_Form(Y);
Y := B_Form(X); -- the reverse conversion
69 Examples of conversions between array types:
70 type Sequence is array (Integer range <>) of Integer;
subtype Dozen is Sequence(1 .. 12);
Ledger : array(1 .. 100) of Integer;
71 Sequence(Ledger) -- bounds are those of Ledger
Sequence(Ledger(31 .. 42)) -- bounds are 31 and 42
Dozen(Ledger(31 .. 42)) -- bounds are those of Dozen
4.7 Qualified Expressions
1 A qualified_expression is used to state explicitly the type, and to
verify the subtype, of an operand that is either an expression or an
aggregate.
Syntax
2 qualified_expression ::=
subtype_mark'(expression) | subtype_mark'aggregate
Name Resolution Rules
3 The operand (the expression or aggregate) shall resolve to be of the type
determined by the subtype_mark, or a universal type that covers it.
Dynamic Semantics
4 The evaluation of a qualified_expression evaluates the operand (and if of
a universal type, converts it to the type determined by the subtype_mark) and
checks that its value belongs to the subtype denoted by the subtype_mark.
The exception Constraint_Error is raised if this check fails.
NOTES
5 (23) When a given context does not uniquely identify an expected type, a
qualified_expression can be used to do so. In particular, if an
overloaded name or aggregate is passed to an overloaded subprogram, it
might be necessary to qualify the operand to resolve its type.
Examples
6 Examples of disambiguating expressions using qualification:
7 type Mask is (Fix, Dec, Exp, Signif);
type Code is (Fix, Cla, Dec, Tnz, Sub);
8 Print (Mask'(Dec)); -- Dec is of type Mask
Print (Code'(Dec)); -- Dec is of type Code
9 for J in Code'(Fix) .. Code'(Dec) loop ... -- qualification needed for eith\
er Fix or Dec
for J in Code range Fix .. Dec loop ... -- qualification unnecessary
for J in Code'(Fix) .. Dec loop ... -- qualification unnecessary for\
Dec
10 Dozen'(1 | 3 | 5 | 7 => 2, others => 0) -- see 4.6
4.8 Allocators
1 The evaluation of an allocator creates an object and yields an access
value that designates the object.
Syntax
2 allocator ::=
new subtype_indication | new qualified_expression
Name Resolution Rules
3 The expected type for an allocator shall be a single access-to-object
type whose designated type covers the type determined by the subtype_mark of
the subtype_indication or qualified_expression.
Legality Rules
4 An initialized allocator is an allocator with a qualified_expression. An
uninitialized allocator is one with a subtype_indication. In the subtype_
indication of an uninitialized allocator, a constraint is permitted only if
the subtype_mark denotes an unconstrained composite subtype; if there is no
constraint, then the subtype_mark shall denote a definite subtype.
5 If the type of the allocator is an access-to-constant type, the allocator
shall be an initialized allocator. If the designated type is limited, the
allocator shall be an uninitialized allocator.
Static Semantics
6 If the designated type of the type of the allocator is elementary, then
the subtype of the created object is the designated subtype. If the
designated type is composite, then the created object is always constrained;
if the designated subtype is constrained, then it provides the constraint of
the created object; otherwise, the object is constrained by its initial value
(even if the designated subtype is unconstrained with defaults).
Dynamic Semantics
7 For the evaluation of an allocator, the elaboration of the subtype_
indication or the evaluation of the qualified_expression is performed first.
For the evaluation of an initialized allocator, an object of the designated
type is created and the value of the qualified_expression is converted to the
designated subtype and assigned to the object.
8 For the evaluation of an uninitialized allocator:
9 If the designated type is elementary, an object of the designated
subtype is created and any implicit initial value is assigned;
10 If the designated type is composite, an object of the designated
type is created with tag, if any, determined by the subtype_mark
of the subtype_indication; any per-object constraints on
subcomponents are elaborated and any implicit initial values for
the subcomponents of the object are obtained as determined by the
subtype_indication and assigned to the corresponding subcom-
ponents. A check is made that the value of the object
belongs to the designated subtype. Constraint_Error is raised
if this check fails. This check and the initialization of the
object are performed in an arbitrary order.
11 If the created object contains any tasks, they are activated (see 9.2).
Finally, an access value that designates the created object is returned.
NOTES
12 (24) Allocators cannot create objects of an abstract type. See 3.9.3.
13 (25) If any part of the created object is controlled, the initialization
includes calls on corresponding Initialize or Adjust procedures. See
7.6.
14 (26) As explained in 13.11, ``Storage Management'', the storage for an
object allocated by an allocator comes from a storage pool (possibly
user defined). The exception Storage_Error is raised by an allocator if
there is not enough storage. Instances of Unchecked_Deallocation may be
used to explicitly reclaim storage.
15 (27) Implementations are permitted, but not required, to provide garbage
collection (see 13.11.3).
Examples
16 Examples of allocators:
17 new Cell'(0, null, null) -- initialized explicitly\
, see 3.10.1
new Cell'(Value => 0, Succ => null, Pred => null) -- initialized explicitly
new Cell -- not initialized
18 new Matrix(1 .. 10, 1 .. 20) -- the bounds only are gi\
ven
new Matrix'(1 .. 10 => (1 .. 20 => 0.0)) -- initialized explicitly
19 new Buffer(100) -- the discriminant only \
is given
new Buffer'(Size => 80, Pos => 0, Value => (1 .. 80 => 'A')) -- initialized\
explicitly
20 Expr_Ptr'(new Literal) -- allocator for access-to-cl\
ass-wide type, see 3.9.1
Expr_Ptr'(new Literal'(Expression with 3.5)) -- initialized explicitly
4.9 Static Expressions and Static Subtypes
1 Certain expressions of a scalar or string type are defined to be static.
Similarly, certain discrete ranges are defined to be static, and certain
scalar and string subtypes are defined to be static subtypes. Static means
determinable at compile time, using the declared properties or values of the
program entities.
2 A static expression is a scalar or string expression that is one of the
following:
3 a numeric_literal;
4 a string_literal of a static string subtype;
5 a name that denotes the declaration of a named number or a static
constant;
6 a function_call whose function_name or function_prefix statically
denotes a static function, and whose actual parameters, if any
(whether given explicitly or by default), are all static
expressions;
7 an attribute_reference that denotes a scalar value, and whose
prefix denotes a static scalar subtype;
8 an attribute_reference whose prefix statically denotes a
statically constrained array object or array subtype, and whose
attribute_designator is First, Last, or Length, with an optional
dimension;
9 a type_conversion whose subtype_mark denotes a static scalar
subtype, and whose operand is a static expression;
10 a qualified_expression whose subtype_mark denotes a static
(scalar or string) subtype, and whose operand is a static
expression;
11 a membership test whose simple_expression is a static expression,
and whose range is a static range or whose subtype_mark denotes a
static (scalar or string) subtype;
12 a short-circuit control form both of whose relations are static
expressions;
13 a static expression enclosed in parentheses.
14 A name statically denotes an entity if it denotes the entity and:
15 It is a direct_name, expanded name, or character_literal, and it
denotes a declaration other than a renaming_declaration; or
16 It is an attribute_reference whose prefix statically denotes some
entity; or
17 It denotes a renaming_declaration with a name that statically
denotes the renamed entity.
18 A static function is one of the following:
19 a predefined operator whose parameter and result types are all
scalar types none of which are descendants of formal scalar
types;
20 a predefined concatenation operator whose result type is a string
type;
21 an enumeration literal;
22 a language-defined attribute that is a function, if the prefix
denotes a static scalar subtype, and if the parameter and result
types are scalar.
23 In any case, a generic formal subprogram is not a static function.
24 A static constant is a constant view declared by a full constant
declaration or an object_renaming_declaration with a static nominal subtype,
having a value defined by a static scalar expression or by a static string
expression whose value has a length not exceeding the maximum length of a
string_literal in the implementation.
25 A static range is a range whose bounds are static expressions, or a
range_attribute_reference that is equivalent to such a range. A static
discrete_range is one that is a static range or is a subtype_indication that
defines a static scalar subtype. The base range of a scalar type is a static
range, unless the type is a descendant of a formal scalar type.
26 A static subtype is either a static scalar subtype or a static string
subtype. A static scalar subtype is an unconstrained scalar subtype whose
type is not a descendant of a formal scalar type, or a constrained scalar
subtype formed by imposing a compatible static constraint on a static scalar
subtype. A static string subtype is an unconstrained string subtype whose
index subtype and component subtype are static (and whose type is not a
descendant of a formal array type), or a constrained string subtype formed by
imposing a compatible static constraint on a static string subtype. In any
case, the subtype of a generic formal object of mode in out, and the result
subtype of a generic formal function, are not static.
27 The different kinds of static constraint are defined as follows:
28 A null constraint is always static;
29 A scalar constraint is static if it has no range_constraint, or
one with a static range;
30 An index constraint is static if each discrete_range is static,
and each index subtype of the corresponding array type is static;
31 A discriminant constraint is static if each expression of the
constraint is static, and the subtype of each discriminant is
static.
32 A subtype is statically constrained if it is constrained, and its
constraint is static. An object is statically constrained if its nominal
subtype is statically constrained, or if it is a static string constant.
Legality Rules
33 A static expression is evaluated at compile time except when it is part
of the right operand of a static short-circuit control form whose value is
determined by its left operand. This evaluation is performed exactly,
without performing Overflow_Checks. For a static expression that is
evaluated:
34 The expression is illegal if its evaluation fails a
language-defined check other than Overflow_Check.
35 If the expression is not part of a larger static expression, then
its value shall be within the base range of its expected type.
Otherwise, the value may be arbitrarily large or small.
36 If the expression is of type universal_real and its expected type
is a decimal fixed point type, then its value shall be a multiple
of the small of the decimal type.
37 The last two restrictions above do not apply if the expected type is a
descendant of a formal scalar type (or a corresponding actual type in an
instance).
Implementation Requirements
38 For a real static expression that is not part of a larger static
expression, and whose expected type is not a descendant of a formal scalar
type, the implementation shall round or truncate the value (according to the
Machine_Rounds attribute of the expected type) to the nearest machine number
of the expected type; if the value is exactly half-way between two machine
numbers, any rounding shall be performed away from zero. If the expected
type is a descendant of a formal scalar type, no special rounding or
truncating is required -- normal accuracy rules apply (see Annex G).
NOTES
39 (28) An expression can be static even if it occurs in a context where
staticness is not required.
40 (29) A static (or run-time) type_conversion from a real type to an
integer type performs rounding. If the operand value is exactly
half-way between two integers, the rounding is performed away from zero.
Examples
41 Examples of static expressions:
42 1 + 1 -- 2
abs(-10)*3 -- 30
43 Kilo : constant := 1000;
Mega : constant := Kilo*Kilo; -- 1_000_000
Long : constant := Float'Digits*2;
44 Half_Pi : constant := Pi/2; -- see 3.3.2
Deg_To_Rad : constant := Half_Pi/90;
Rad_To_Deg : constant := 1.0/Deg_To_Rad; -- equivalent to 1.0/((3.14159_265\
36/2)/90)
4.9.1 Statically Matching Constraints and Subtypes
Static Semantics
1 A constraint statically matches another constraint if both are null
constraints, both are static and have equal corresponding bounds or
discriminant values, or both are nonstatic and result from the same
elaboration of a constraint of a subtype_indication or the same evaluation of
a range of a discrete_subtype_definition.
2 A subtype statically matches another subtype of the same type if they
have statically matching constraints. Two anonymous access subtypes
statically match if their designated subtypes statically match.
3 Two ranges of the same type statically match if both result from the same
evaluation of a range, or if both are static and have equal corresponding
bounds.
4 A constraint is statically compatible with a scalar subtype if it
statically matches the constraint of the subtype, or if both are static and
the constraint is compatible with the subtype. A constraint is statically
compatible with an access or composite subtype if it statically matches the
constraint of the subtype, or if the subtype is unconstrained. One subtype
is statically compatible with a second subtype if the constraint of the first
is statically compatible with the second subtype.
Section 5: Statements
1 A statement defines an action to be performed upon its execution.
2 This section describes the general rules applicable to all statements.
Some statements are discussed in later sections: Procedure_call_statements
and return_statements are described in Section 6, ``Subprograms''. Entry_
call_statements, requeue_statements, delay_statements, accept_statements,
select_statements, and abort_statements are described in Section 9, ``Tasks
and Synchronization''. Raise_statements are described in Section 11,
``Exceptions'', and code_statements in Section 13. The remaining forms of
statements are presented in this section.
5.1 Simple and Compound Statements - Sequences of Statements
1 A statement is either simple or compound. A simple_statement encloses no
other statement. A compound_statement can enclose simple_statements and
other compound_statements.
Syntax
2 sequence_of_statements ::= statement {statement}
3 statement ::=
{label} simple_statement | {label} compound_statement
4 simple_statement ::= null_statement
| assignment_statement | exit_statement
| goto_statement | procedure_call_statement
| return_statement | entry_call_statement
| requeue_statement | delay_statement
| abort_statement | raise_statement
| code_statement
5 compound_statement ::=
if_statement | case_statement
| loop_statement | block_statement
| accept_statement | select_statement
6 null_statement ::= null;
7 label ::= <>
8 statement_identifier ::= direct_name
9 The direct_name of a statement_identifier shall be an identifier (not
an operator_symbol).
Name Resolution Rules
10 The direct_name of a statement_identifier shall resolve to denote its
corresponding implicit declaration (see below).
Legality Rules
11 Distinct identifiers shall be used for all statement_identifiers that
appear in the same body, including inner block_statements but excluding inner
program units.
Static Semantics
12 For each statement_identifier, there is an implicit declaration (with
the specified identifier) at the end of the declarative_part of the innermost
block_statement or body that encloses the statement_identifier. The implicit
declarations occur in the same order as the statement_identifiers occur in
the source text. If a usage name denotes such an implicit declaration, the
entity it denotes is the label, loop_statement, or block_statement with the
given statement_identifier.
Dynamic Semantics
13 The execution of a null_statement has no effect.
14 A transfer of control is the run-time action of an exit_statement,
return_statement, goto_statement, or requeue_statement, selection of a
terminate_alternative, raising of an exception, or an abort, which causes the
next action performed to be one other than what would normally be expected
from the other rules of the language. As explained in 7.6.1, a transfer of
control can cause the execution of constructs to be completed and then left,
which may trigger finalization.
15 The execution of a sequence_of_statements consists of the execution of
the individual statements in succession until the sequence_ is completed.
NOTES
16 (1) A statement_identifier that appears immediately within the
declarative region of a named loop_statement or an accept_statement is
nevertheless implicitly declared immediately within the declarative
region of the innermost enclosing body or block_statement; in other
words, the expanded name for a named statement is not affected by
whether the statement occurs inside or outside a named loop or an
accept_statement -- only nesting within block_statements is relevant to
the form of its expanded name.
Examples
17 Examples of labeled statements:
18 <> <> <> <> null;
19 <> X := 1;
5.2 Assignment Statements
1 An assignment_statement replaces the current value of a variable with the
result of evaluating an expression.
Syntax
2 assignment_statement ::=
variable_name := expression;
3 The execution of an assignment_statement includes the evaluation of the
expression and the assignment of the value of the expression into the target.
An assignment operation (as opposed to an assignment_statement) is performed
in other contexts as well, including object initialization and by-copy
parameter passing. The target of an assignment operation is the view of the
object to which a value is being assigned; the target of an assignment_
statement is the variable denoted by the variable_name.
Name Resolution Rules
4 The variable_name of an assignment_statement is expected to be of any
nonlimited type. The expected type for the expression is the type of the
target.
Legality Rules
5 The target denoted by the variable_name shall be a variable.
6 If the target is of a tagged class-wide type T'Class, then the expression
shall either be dynamically tagged, or of type T and tag-indeterminate (see
3.9.2).
Dynamic Semantics
7 For the execution of an assignment_statement, the variable_name and the
expression are first evaluated in an arbitrary order.
8 When the type of the target is class-wide:
9 If the expression is tag-indeterminate (see 3.9.2), then the
controlling tag value for the expression is the tag of the
target;
10 Otherwise (the expression is dynamically tagged), a check is made
that the tag of the value of the expression is the same as that
of the target; if this check fails, Constraint_Error is raised.
11 The value of the expression is converted to the subtype of the target.
The conversion might raise an exception (see 4.6).
12 In cases involving controlled types, the target is finalized, and an
anonymous object might be used as an intermediate in the assignment, as
described in 7.6.1, ``Completion and Finalization''. In any case, the
converted value of the expression is then assigned to the target, which
consists of the following two steps:
13 The value of the target becomes the converted value.
14 If any part of the target is controlled, its value is adjusted as
explained in clause 7.6.
NOTES
15 (2) The tag of an object never changes; in particular, an assignment_