- This subclause defines completion and leaving of the execution of constructs
and entities. A master is the execution of a construct that includes finalization
of local objects after it is complete (and after waiting for any local tasks
-- see 9.3), but before leaving. Other constructs
and entities are left immediately upon completion.
- The execution of a construct or entity is complete when the end of that
execution has been reached, or when a transfer of control (see
5.1) causes it to be abandoned. Completion due to reaching the end of
execution, or due to the transfer of control of an exit_, return_, goto_,
or requeue_statement or of the selection of a terminate_alternative is normal
completion. Completion is abnormal otherwise -- when control is transferred
out of a construct due to abort or the raising of an exception.
- After execution of a construct or entity is complete, it is left, meaning
that execution continues with the next action, as defined for the execution
that is taking place. Leaving an execution happens immediately after its
completion, except in the case of a master: the execution of a task_body, a
block_statement, a subprogram_body, an entry_body, or an accept_statement. A
master is finalized after it is complete, and before it is left.
- For the finalization of a master, dependent tasks are first awaited, as
explained in 9.3. Then each object whose accessibility
level is the same as that of the master is finalized if the object was successfully
initialized and still exists. These actions are performed whether the master
is left by reaching the last statement or via a transfer of control. When
a transfer of control causes completion of an execution, each included master
is finalized in order, from innermost outward.
- For the finalization of an object:
- If the object is of an elementary type, finalization has no
- If the object is of a controlled type, the Finalize procedure is
- If the object is of a protected type, the actions defined in
9.4 are performed;
- If the object is of a composite type, then after performing the
above actions, if any, every component of the object is finalized
in an arbitrary order, except as follows: if the object has a
component with an access discriminant constrained by a per-object
expression, this component is finalized before any components
that do not have such discriminants; for an object with several
components with such a discriminant, they are finalized in the
reverse of the order of their component_declarations.
- Immediately before an instance of Unchecked_Deallocation reclaims the
storage of an object, the object is finalized. If an instance of Unchecked_Deallocation is never applied to an object created by an allocator, the
object will still exist when the corresponding master completes, and it will
be finalized then.
- The order in which the finalization of a master performs finalization of
objects is as follows: Objects created by declarations in the master are finalized
in the reverse order of their creation. For objects that were created by allocators
for an access type whose ultimate ancestor is declared in the master, this
rule is applied as though each such object that still exists had been created
in an arbitrary order at the first freezing point (see
13.14) of the ultimate ancestor type.
- The target of an assignment statement is finalized before copying in the
new value, as explained in 7.6.
- The anonymous objects created by function calls and by aggregates are
finalized no later than the end of the innermost enclosing declarative_item
or statement; if that is a compound_statement, they are finalized before
starting the execution of any statement within the compound_statement.
Bounded (Run-Time) Errors
- It is a bounded error for a call on Finalize or Adjust to propagate an
exception. The possible consequences depend on what action invoked the
Finalize or Adjust operation:
- For a Finalize invoked as part of an assignment_statement,
Program_Error is raised at that point.
- For an Adjust invoked as part of an assignment operation, any
other adjustments due to be performed are performed, and then
Program_Error is raised.
- For a Finalize invoked as part of a call on an instance of
Unchecked_Deallocation, any other finalizations due to be
performed are performed, and then Program_Error is raised.
- For a Finalize invoked by the transfer of control of an exit_,
return_, goto_, or requeue_statement, Program_Error is raised no
earlier than after the finalization of the master being finalized
when the exception occurred, and no later than the point where
normal execution would have continued. Any other finalizations
due to be performed up to that point are performed before raising
- For a Finalize invoked by a transfer of control that is due to
raising an exception, any other finalizations due to be performed
for the same master are performed; Program_Error is raised
immediately after leaving the master.
- For a Finalize invoked by a transfer of control due to an abort
or selection of a terminate alternative, the exception is
ignored; any other finalizations due to be performed are
(18) The rules of Section 10 imply that immediately
prior to partition termination, Finalize operations are applied to library-level
controlled objects (including those created by allocators of library-level
access types, except those already finalized). This occurs after waiting
for library-level tasks to terminate.
(19) A constant is only constant between its initialization and
finalization. Both initialization and finalization are allowed to
change the value of a constant.
(20) Abort is deferred during certain operations related to controlled types,
as explained in 9.8. Those rules prevent an abort
from causing a controlled object to be left in an ill-defined state.
(21) The Finalize procedure is called upon finalization of a controlled
object, even if Finalize was called earlier, either explicitly or as
part of an assignment; hence, if a controlled type is visibly controlled
(implying that its Finalize primitive is directly callable), or is
nonlimited (implying that assignment is allowed), its Finalize procedure
should be designed to have no ill effect if it is applied a second time
to the same object.
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Page last generated: 95-03-12