Go to the first, previous, next, last section, table of contents.
-
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 section 9.3 Task Dependence - Termination of Tasks.), but before leaving. Other
constructs and entities are left immediately upon completion.
Dynamic Semantics
-
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 section 5.1 Simple and Compound Statements - Sequences of Statements,
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 See section 9.3 Task Dependence - Termination of Tasks. 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 effect;
-
If the object is of a controlled type, the Finalize procedure is called;
-
If the object is of a protected type, the actions defined in See section 9.4 Protected Units and Protected Objects, 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 section 13.14 Freezing Rules, of the ultimate ancestor type.
-
The target of an assignment statement is finalized before copying in the
new value, as explained in See section 7.6 User-Defined Assignment and Finalization.
-
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 Program_Error.
-
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 performed.
NOTES
-
(18) The rules of See section 10 Program Structure and Compilation Issues, 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 See section 9.8 Abort of a Task - Abort of a Sequence of Statements. 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.
Go to the first, previous, next, last section, table of contents.