- (1)
- The evaluation of an allocator creates an object and yields an access
value that designates the object.
(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 subcomponents. 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.
-
- (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 given
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')) -- initializedexplicitly
(20)
Expr_Ptr'(new Literal) -- allocator for access-to-class-wide type, see 3.9.1
Expr_Ptr'(new Literal'(Expression with 3.5)) -- initialized explicitly
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Copyright statement
Page last generated: 95-03-12