3.10 Access Types
A
value of an access type (an
access value) provides indirect access
to the object or subprogram it
designates. Depending on its type,
an access value can designate either subprograms, objects created by
allocators (see
4.8), or more generally
aliased
objects of an appropriate type.
Syntax
general_access_modifier ::= all |
constant
null_exclusion ::= not null
Static Semantics
There
are two kinds of access types,
access-to-object types, whose values
designate objects, and
access-to-subprogram types, whose values
designate subprograms.
Associated with an access-to-object
type is a
storage pool; several access types may share the same
storage pool. All descendants of an access type share the same storage
pool.
A storage pool is an area of storage used to
hold dynamically allocated objects (called
pool elements) created
by allocators; storage pools are described further in
13.11,
“
Storage Management”.
Access-to-object
types are further subdivided into
pool-specific access types,
whose values can designate only the elements of their associated storage
pool, and
general access types, whose values can designate the
elements of any storage pool, as well as aliased objects created by declarations
rather than allocators, and aliased subcomponents of other objects.
A view of an object is defined
to be
aliased if it is defined by an
object_declaration
or
component_definition
with the reserved word
aliased, or by a renaming of an aliased
view. In addition, the dereference of an access-to-object value denotes
an aliased view, as does a view conversion (see
4.6)
of an aliased view. The current instance of a limited tagged type, a
protected type, a task type, or a type that has the reserved word
limited
in its full definition is also defined to be aliased. Finally, a formal
parameter or generic formal object of a tagged type is defined to be
aliased. Aliased views are the ones that can be designated by an access
value.
An
access_to_object_definition
defines an access-to-object type and its first subtype;
the
subtype_indication
defines the
designated subtype of the access type. If a
general_access_modifier
appears, then the access type is a general access type.
If
the modifier is the reserved word
constant, then the type is an
access-to-constant type; a designated object cannot be updated
through a value of such a type.
If the modifier is
the reserved word
all, then the type is an
access-to-variable
type; a designated object can be both read and updated through a
value of such a type. If no
general_access_modifier
appears in the
access_to_object_definition,
the access type is a pool-specific access-to-variable type.
An
access_to_subprogram_definition
defines an access-to-subprogram type and its first subtype;
the
parameter_profile
or
parameter_and_result_profile
defines the
designated profile of the access type.
There
is a
calling convention associated with the designated profile;
only subprograms with this calling convention can be designated by values
of the access type. By default, the calling convention is “
protected”
if the reserved word
protected appears, and “Ada”
otherwise. See
Annex B for how to override this
default.
For each access type, there is
a null access value designating no entity at all, which can be obtained
by (implicitly) converting the literal
null to the access type.
The null value of an access type is the default initial value of the
type. Non-null values of an access-to-object type are obtained by evaluating
an
allocator,
which returns an access value designating a newly created object (see
3.10.2), or in the case of a general access-to-object
type, evaluating an
attribute_reference
for the Access or Unchecked_Access attribute of an aliased view of an
object. Non-null values of an access-to-subprogram type are obtained
by evaluating an
attribute_reference
for the Access attribute of a non-intrinsic subprogram..
All subtypes
of an access-to-subprogram type are constrained. The first subtype of
a type defined by an
access_definition
or an
access_to_object_definition
is unconstrained if the designated subtype is an unconstrained array
or discriminated subtype; otherwise it is constrained.
Legality Rules
Dynamic Semantics
A
composite_constraint
is
compatible with an unconstrained access subtype if it is compatible
with the designated subtype. A
null_exclusion
is compatible with any access subtype that does not exclude null.
An
access value
satisfies a
composite_constraint
of an access subtype if it equals the null value of its type or if it
designates an object whose value satisfies the constraint. An access
value satisfies an exclusion of the null value if it does not equal the
null value of its type.
The elaboration of an
access_type_definition
creates the access type and its first subtype. For an access-to-object
type, this elaboration includes the elaboration of the
subtype_indication,
which creates the designated subtype.
80 Access values are called “pointers”
or “references” in some other languages.
81 Each access-to-object type has an associated
storage pool; several access types can share the same pool. An object
can be created in the storage pool of an access type by an
allocator
(see
4.8) for the access type. A storage pool
(roughly) corresponds to what some other languages call a “heap.”
See
13.11 for a discussion of pools.
Examples
Examples of access-to-object
types:
type Peripheral_Ref
is not null access Peripheral; --
see 3.8.1
type Binop_Ptr
is access all Binary_Operation'Class;
--
general access-to-class-wide, see 3.9.1
Example of an access
subtype:
subtype Drum_Ref
is Peripheral_Ref(Drum); --
see 3.8.1
Example of an access-to-subprogram
type:
type Message_Procedure is access procedure (M : in String := "Error!");
procedure Default_Message_Procedure(M : in String);
Give_Message : Message_Procedure := Default_Message_Procedure'Access;
...
procedure Other_Procedure(M : in String);
...
Give_Message := Other_Procedure'Access;
...
Give_Message("File not found."); -- call with parameter (.all is optional)
Give_Message.all; -- call with no parameters