Contents Index Search Previous Next
10.2.1 Elaboration Control
1
[
{elaboration control}
This subclause defines pragmas that help control
the elaboration order of
library_items.]
Language Design Principles
1.a
The rules governing preelaboration
are designed to allow it to be done largely by bulk initialization of
statically allocated storage from information in a ``load module'' created
by a linker. Some implementations may require run-time code to be executed
in some cases, but we consider these cases rare enough that we need not
further complicate the rules.
1.b
It is important that programs
be able to declare data structures that are link-time initialized with
aggregates, string_literals,
and concatenations thereof. It is important to be able to write link-time
evaluated expressions involving the First, Last, and Length attributes
of such data structures (including variables), because they might be
initialized with positional aggregates
or string_literals, and we don't
want the user to have to count the elements. There is no corresponding
need for accessing discriminants, since they can be initialized with
a static constant, and then the constant can be referred to elsewhere.
It is important to allow link-time initialized data structures involving
discriminant-dependent components. It is important to be able to write
link-time evaluated expressions involving pointers (both access values
and addresses) to the above-mentioned data structures.
1.c
The rules also ensure that no
Elaboration_Check need be performed for calls on library-level subprograms
declared within a preelaborated package. This is true also of the Elaboration_Check
on task activation for library level task types declared in a preelaborated
package. However, it is not true of the Elaboration_Check on instantiations.
1.d
A static expression should never
prevent a library unit from being preelaborable.
Syntax
2
The form of
a pragma Preelaborate is as follows:
3
pragma Preelaborate[(
library_unit_name)];
4
{library unit pragma (Preelaborate)
[partial]} {pragma, library
unit (Preelaborate) [partial]} A
pragma
Preelaborate is a library unit pragma.
Legality Rules
5
{preelaborable
(of an elaborable construct) [distributed]} An
elaborable construct is preelaborable unless its elaboration performs
any of the following actions:
5.a
Ramification: A preelaborable
construct can be elaborated without using any information that is available
only at run time. Note that we don't try to prevent exceptions in preelaborable
constructs; if the implementation wishes to generate code to raise an
exception, that's OK.
5.b
Because there is no flow of
control and there are no calls (other than to predefined subprograms),
these run-time properties can actually be detected at compile time. This
is necessary in order to require compile-time enforcement of the rules.
6
- The execution of a statement
other than a null_statement.
6.a
Ramification: A preelaborable
construct can contain labels and
null_statements.
7
- A call to a subprogram other than
a static function.
8
- The evaluation of a primary
that is a name of an object, unless
the name is a static expression,
or statically denotes a discriminant of an enclosing type.
8.a
Ramification: One can
evaluate such a name, but not as
a primary. For example, one can
evaluate an attribute of the object. One can evaluate an attribute_reference,
so long as it does not denote an object, and its prefix
does not disobey any of these rules. For example, Obj'Access, Obj'Unchecked_Access,
and Obj'Address are generally legal in preelaborated library units.
9
- The creation of a default-initialized
object [(including a component)] of a descendant of a private type, private
extension, controlled type, task type, or protected type with entry_declarations;
similarly the evaluation of an extension_aggregate
with an ancestor subtype_mark denoting
a subtype of such a type.
9.a
Ramification: One can
declare these kinds of types, but one cannot create objects of those
types.
9.b
It is also non-preelaborable
to create an object if that will cause the evaluation of a default expression
that will call a user-defined function. This follows from the rule above
forbidding non-null statements.
9.c
Reason: Controlled objects
are disallowed because most implementations will have to take some run-time
action during initialization, even if the Initialize procedure is null.
10
A generic body is preelaborable only if elaboration
of a corresponding instance body would not perform any such actions,
presuming that the actual for each formal private type (or extension)
is a private type (or extension), and the actual for each formal subprogram
is a user-defined subprogram.
{generic contract issue}
10.a
Reason: Without this
rule about generics, we would have to forbid instantiations in preelaborated
library units, which would significantly reduce their usefulness.
11/1
{
8652/0035}
{
AI95-00002}
{preelaborated [partial]} If
a
pragma Preelaborate (or
pragma
Pure -- see below) applies to a library unit, then it is
preelaborated.
[
{preelaborated [distributed]} If
a library unit is preelaborated, then its declaration, if any, and body,
if any, are elaborated prior to all non-preelaborated
library_items
of the partition.]
The declaration and body of a preelaborated library
unit, and all subunits that are elaborated as part of elaborating the
library unit, All compilation units of a preelaborated library
unit shall be preelaborable.
{generic contract
issue [partial]} 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. In addition, all compilation units of a preelaborated library unit
shall depend semantically only on compilation units of other preelaborated
library units.
11.a
Ramification: In a generic
body, we assume the worst about formal private types and extensions.
11.a.1/1
{8652/0035}
{AI95-00002}
Subunits of a preelaborated subprogram unit do not need to be preelaborable.
This is needed in order to be consistent with units nested in a subprogram
body, which do not need to be preelaborable even if the subprogram is
preelaborated. However, such subunits cannot depend semantically on non-preelaborated
units, which is also consistent with nested units.
Implementation Advice
12
In an implementation, a type declared in a preelaborated
package should have the same representation in every elaboration of a
given version of the package, whether the elaborations occur in distinct
executions of the same program, or in executions of distinct programs
or partitions that include the given version.
Syntax
13
The form of
a pragma Pure is as follows:
14
pragma Pure[(
library_unit_name)];
15
{library unit pragma (Pure)
[partial]} {pragma, library
unit (Pure) [partial]} A
pragma
Pure is a library unit pragma.
Legality Rules
16
{pure} A
pure library_item is a preelaborable
library_item that does not contain
the declaration of any variable or named access type, except within a
subprogram, generic subprogram, task unit, or protected unit.
17
{declared pure}
A
pragma Pure
is used to declare that a library unit is pure. If a
pragma
Pure applies to a library unit, then its compilation units shall be pure,
and they shall depend semantically only on compilation units of other
library units that are declared pure.
17.a
To be honest: A declared-pure
library unit is one to which a pragma
Pure applies. Its declaration and body are also said to be declared pure.
17.b
Discussion: A declared-pure
package is useful for defining types to be shared between partitions
with no common address space.
17.c
Reason: Note that generic
packages are not mentioned in the list of things that can contain variable
declarations. Note that the Ada 95 rules for deferred constants make
them allowable in library units that are declared pure; that isn't true
of Ada 83's deferred constants.
17.d
Ramification: Anonymous
access types (that is, access discriminants and access parameters) are
allowed.
17.e
Reason: The primary reason
for disallowing named access types is that an allocator
has a side effect; the pool constitutes variable data. We considered
somehow allowing allocator-less
access types. However, these (including access-to-subprogram types) would
cause trouble for Annex E, ``Distributed
Systems'', because such types would allow access values in a shared
passive partition to designate objects in an active partition, thus allowing
inter-address space references. Furthermore, a named access-to-object
type without a pool would be a new concept, adding complexity from the
user's point of view. Finally, the prevention of allocators
would have to be a run-time check, in order to avoid violations of the
generic contract model.
Implementation Permissions
18
If a library unit is declared pure, then the
implementation is permitted to omit a call on a library-level subprogram
of the library unit if the results are not needed after the call. Similarly,
it may omit such a call and simply reuse the results produced by an earlier
call on the same subprogram, provided that none of the parameters are
of a limited type, and the addresses and values of all by-reference actual
parameters, and the values of all by-copy-in actual parameters, are the
same as they were at the earlier call. [This permission applies even
if the subprogram produces other side effects when called.]
18.a
Discussion: A declared-pure
library_item has no variable state.
Hence, a call on one of its (nonnested) subprograms cannot ``normally''
have side effects. The only possible side effects from such a call would
be through machine code insertions, unchecked conversion to an access
type declared within the subprogram, and similar features. The compiler
may omit a call to such a subprogram even if such side effects exist,
so the writer of such a subprogram has to keep this in mind.
Syntax
19
The form of
a pragma Elaborate, Elaborate_All,
or Elaborate_Body is as follows:
20
pragma Elaborate(
library_unit_name{,
library_unit_name});
21
pragma Elaborate_All(
library_unit_name{,
library_unit_name});
22
pragma Elaborate_Body[(
library_unit_name)];
23
A pragma
Elaborate or Elaborate_All is only allowed within a context_clause.
23.a
Ramification: ``Within
a context_clause'' allows it to
be the last item in the context_clause.
It can't be first, because the name
has to denote something mentioned earlier.
24
{library unit pragma (Elaborate_Body)
[partial]} {pragma, library
unit (Elaborate_Body) [partial]} A
pragma
Elaborate_Body is a library unit pragma.
24.a
Discussion: Hence, a
pragma Elaborate or Elaborate_All
is not elaborated, not that it makes any practical difference.
24.b
Note that a pragma
Elaborate or Elaborate_All is neither a program unit pragma, nor a library
unit pragma.
Legality Rules
25
{requires a completion (declaration
to which a pragma Elaborate_Body applies) [partial]} If
a
pragma Elaborate_Body applies
to a declaration, then the declaration requires a completion [(a body)].
Static Semantics
26
[A pragma
Elaborate specifies that the body of the named library unit is elaborated
before the current library_item.
A pragma Elaborate_All specifies
that each library_item that is needed
by the named library unit declaration is elaborated before the current
library_item. A pragma
Elaborate_Body specifies that the body of the library unit is elaborated
immediately after its declaration.]
26.a
Proof: The official statement
of the semantics of these pragmas
is given in 10.2.
26.b
Implementation Note: The
presence of a pragma Elaborate_Body
simplifies the removal of unnecessary Elaboration_Checks. For a subprogram
declared immediately within a library unit to which a pragma
Elaborate_Body applies, the only calls that can fail the Elaboration_Check
are those that occur in the library unit itself, between the declaration
and body of the called subprogram; if there are no such calls (which
can easily be detected at compile time if there are no stubs),
then no Elaboration_Checks are needed for that subprogram. The same is
true for Elaboration_Checks on task activations and instantiations, and
for library subprograms and generic units.
26.c
Ramification: The fact
that the unit of elaboration is the library_item
means that if a subprogram_body
is not a completion, it is impossible for any library_item
to be elaborated between the declaration and the body of such a subprogram.
Therefore, it is impossible for a call to such a subprogram to fail its
Elaboration_Check.
26.d
Discussion: The visibility
rules imply that each library_unit_name
of a pragma Elaborate or Elaborate_All
has to denote a library unit mentioned by a previous with_clause
of the same context_clause.
27
12 A preelaborated library
unit is allowed to have non-preelaborable children.
27.a/1
Ramification: {8652/0035}
{AI95-00002}
But generally not non-preelaborated subunits. (Non-preelaborated
subunits of subprograms are allowed as discussed above.)
28
13 A library unit that
is declared pure is allowed to have impure children.
28.a/1
Ramification: {8652/0035}
{AI95-00002}
But generally not impure subunits. (Impure subunits of subprograms
are allowed as discussed above.)
28.b
Ramification: Pragma
Elaborate is mainly for closely related library units, such as when two
package bodies 'with' each other's declarations. In such cases, Elaborate_All
sometimes won't work.
Extensions to Ada 83
28.c
{extensions to Ada 83}
The concepts of preelaborability and purity are new
to Ada 95. The Elaborate_All, Elaborate_Body, Preelaborate, and Pure
pragmas are new to Ada 95.
28.d
Pragmas Elaborate are allowed
to be mixed in with the other things in the context_clause
-- in Ada 83, they were required to appear last.
Contents Index Search Previous Next Legal