Anonymous Access Types

Named and Anonymous Access Types

The previous chapter dealt with access type declarations such as this one:

type Integer_Access is access all Integer;

procedure Add_One (A : Integer_Access);

In addition to named access type declarations such as the one in this example, Ada also supports anonymous access types, which, as the name implies, don't have an actual type declaration.

To declare an access object of anonymous type, we just specify the subtype of the object or subprogram we want to have access to. For example:

procedure Add_One (A : access Integer);

When we compare this example with the previous one, we see that the declaration A : Integer_Access becomes A : access Integer. Here, access Integer is the anonymous access type declaration, and A is an access object of this anonymous type.

To be more precise, A : access Integer is an access parameter and it's specifying an anonymous access-to-object type. Another flavor of anonymous access types are anonymous access-to-subprograms. We discuss all these topics in more details later.

Let's see a complete example:

    
    
    
        
with Ada.Text_IO; use Ada.Text_IO; procedure Show_Anonymous_Access_Types is I_Var : aliased Integer; A : access Integer; -- ^ Anonymous access type begin A := I_Var'Access; -- ^ Assignment to object of -- anonymous access type. A.all := 22; Put_Line ("A.all: " & Integer'Image (A.all)); end Show_Anonymous_Access_Types;

Here, A is an access object whose value is initialized with the access to I_Var. Because the declaration of A includes the declaration of an anonymous access type, we don't declare an extra Integer_Access type, as we did in previous code examples.

In the Ada Reference Manual

Relation to named types

Anonymous access types were not part of the first version of the Ada standard, which only had support for named access types. They were introduced later to cover some use-cases that were difficult — or even impossible — with access types.

In this sense, anonymous access types aren't just access types without names. Certain accessibility rules for anonymous access types are a bit less strict. In those cases, it might be interesting to consider using them instead of named access types.

In general, however, we should only use anonymous access types in those specific cases where using named access types becomes too cumbersome. As a general recommendation, we should give preference to named access types whenever possible. (Anonymous access-to-object types have drawbacks that we discuss later.)

Benefits of anonymous access types

One of the main benefits of anonymous access types is their flexibility: since there isn't an explicit access type declaration associated with them, we only have to worry about the subtype S we intend to access.

Also, as long as the subtype S in a declaration access S is always the same, no conversion is needed between two access objects of that anonymous type, and the S'Access attribute always works.

Let's see an example:

    
    
    
        
with Ada.Text_IO; use Ada.Text_IO; procedure Show (Name : String; V : access Integer) is begin Put_Line (Name & ".all: " & Integer'Image (V.all)); end Show;
with Show; procedure Show_Anonymous_Access_Types is I_Var : aliased Integer; A : access Integer; B : access Integer; begin A := I_Var'Access; B := A; A.all := 22; Show ("A", A); Show ("B", B); end Show_Anonymous_Access_Types;

In this example, we have two access objects A and B. Since they're objects of anonymous access types that refer to the same subtype Integer, we can assign A to B without a type conversion, and pass those access objects as an argument to the Show procedure.

(Note that the use of an access parameter in the Show procedure is for demonstration purpose only: a simply Integer as the type of this input parameter would have been more than sufficient to implement the procedure. Actually, in this case, avoiding the access parameter would be the recommended approach in terms of clean Ada software design.)

In contrast, if we had used named type declarations, the code would be more complicated and more limited:

    
    
    
        
package Aux is type Integer_Access is access all Integer; procedure Show (Name : String; V : Integer_Access); end Aux;
with Ada.Text_IO; use Ada.Text_IO; package body Aux is procedure Show (Name : String; V : Integer_Access) is begin Put_Line (Name & ".all: " & Integer'Image (V.all)); end Show; end Aux;
with Aux; use Aux; procedure Show_Anonymous_Access_Types is -- I_Var : aliased Integer; A : Integer_Access; B : Integer_Access; begin -- A := I_Var'Access; -- ^ ERROR: non-local pointer cannot -- point to local object. A := new Integer; B := A; A.all := 22; Show ("A", A); Show ("B", B); end Show_Anonymous_Access_Types;

Here, apart from the access type declaration (Integer_Access), we had to make two adaptations to convert the previous code example:

  1. We had to move the Show procedure to a package (which we simply called Aux) because of the access type declaration.

  2. Also, we had to allocate an object for A instead of retrieving the access attribute of I_Var because we cannot use a pointer to a local object in the assignment to a non-local pointer, as indicate in the comments.

This restriction regarding non-local pointer assignments is an example of the stricter accessibility rules that apply to named access types. As mentioned earlier, the S'Access attribute always works when we use anonymous access types — this is not always the case for named access types.

Important

As mentioned earlier, if we want to use two access objects in an operation, the rule says that the subtype S of the anonymous type used in their corresponding declaration must match. In the following example, we can see how this rule works:

    
    
    
        
procedure Show_Anonymous_Access_Subtype_Error is subtype Integer_1_10 is Integer range 1 .. 10; I_Var : aliased Integer; A : access Integer := I_Var'Access; B : access Integer_1_10; begin A := I_Var'Access; B := A; -- ^ ERROR: subtype doesn't match! B := I_Var'Access; -- ^ ERROR: subtype doesn't match! end Show_Anonymous_Access_Subtype_Error;

Even though Integer_1_10 is a subtype of Integer, we cannot assign A to B because the subtype that their access type declarations refer to — Integer and Integer_1_10, respectively — doesn't match. The same issue occurs when retrieving the access attribute of I_Var in the assignment to B.

The later sections on anonymous access-to-object type and anonymous access-to-subprograms cover more specific details on anonymous access types.

Anonymous Access-To-Object Types

In the previous chapter, we introduced named access-to-object types and used those types throughout the chapter. Also, in the previous section, we've seen some simple examples of anonymous access-to-object types:

procedure Add_One (A : access Integer);
--                     ^ Anonymous access type

A : access Integer;
--  ^ Anonymous access type

In addition to parameters and objects, we can use anonymous access types in discriminants, components of array and record types, renamings and function return types. (We discuss anonymous access discriminants and anonymous access parameters later on.) Let's see a code example that includes all these cases:

    
    
    
        
package All_Anonymous_Access_To_Object_Types is procedure Add_One (A : access Integer) is null; -- ^ Anonymous access type AI : access Integer; -- ^ Anonymous access type type Rec (AI : access Integer) is private; -- ^ Anonymous access type type Access_Array is array (Positive range <>) of access Integer; -- ^ Anonymous access type Arr : array (1 .. 5) of access Integer; -- ^ Anonymous access type AI_Renaming : access Integer renames AI; -- ^ Anonymous access type function Init_Access_Integer return access Integer is (null); -- ^ Anonymous access type private type Rec (AI : access Integer) is record -- ^ Anonymous access type Internal_AI : access Integer; -- ^ Anonymous access type end record; end All_Anonymous_Access_To_Object_Types;

In this example, we see multiple examples of anonymous access-to-object types:

  • as the A parameter of the Add_One procedure;

  • in the declaration of the AI access object;

  • as the AI discriminant of the Rec type;

  • as the component type of the Access_Array type;

  • as the component type of the Arr array;

  • in the AI_Renaming renaming;

  • as the return type of the Init_Access_Integer;

  • as the Internal_AI of component of the Rec type.

In the Ada Reference Manual

Not Null Anonymous Access-To-Object Types

As expected, null is a valid value for an anonymous access type. However, we can forbid null as a valid value by using not null in the anonymous access type declaration. For example:

    
    
    
        
package All_Anonymous_Access_To_Object_Types is procedure Add_One (A : not null access Integer) is null; -- ^ Anonymous access type I : aliased Integer; AI : not null access Integer := I'Access; -- ^ Anonymous access type -- ^^^^^^^^ -- Initialization required! type Rec (AI : not null access Integer) is private; -- ^ Anonymous access type type Access_Array is array (Positive range <>) of not null access Integer; -- ^ Anonymous access type Arr : array (1 .. 5) of not null access Integer := -- ^ Anonymous access type (others => I'Access); -- ^^^^^^^^^^^^^^^^^^ -- Initialization required! AI_Renaming : not null access Integer renames AI; -- ^ Anonymous access type function Init_Access_Integer return not null access Integer is (I'Access); -- ^ Anonymous access type -- ^^^^^^^^ -- Initialization required! private type Rec (AI : not null access Integer) is record -- ^ Anonymous access type Internal_AI : not null access Integer; -- ^ Anonymous access type end record; end All_Anonymous_Access_To_Object_Types;

As you might have noticed, we took the previous code example and used not null for each usage instance of the anonymous access type. In this sense, this version of the code example is very similar to the previous one. Note, however, that we now have to explicitly initialize some elements to avoid the Constraint_Error exception being raised at runtime. This is the case for example for the AI access object:

AI : not null access Integer := I'Access;

If we hadn't initialized AI explicitly with I'Access, it would have been set to null, which would fail the not null constraint of the anonymous access type. Similarly, we also have to initialize the Arr array and return a valid access object for the Init_Access_Integer function.

Drawbacks of Anonymous Access-To-Object Types

Anonymous access-to-object types have important drawbacks. For example, some features that are available for named access types aren't available for the anonymous access types. Also, most of the drawbacks are related to how anonymous access-to-object types can potentially make the allocation and deallocation quite complicated or even error-prone.

For starters, some pool-related features aren't available for anonymous access-to-object types. For example, we cannot specify which pool is going to be used in the allocation of an anonymous access-to-object. In fact, the memory pool selection is compiler-dependent, so we cannot rely on an object being allocated from a specific pool when using new with an anonymous access-to-object type. (In contrast, as we know, each named access type has an associated pool, so objects allocated via new will be allocated from that pool.) Also, we cannot identify which pool was selected for the allocation of a specific object, so we don't have any information to use for the deallocation of that object.

Because the pool selection is hidden from us, this makes the memory deallocation more complicated. For example, we cannot instantiate the Ada.Unchecked_Deallocation procedure for anonymous access types. Also, some of the methods we could use to circumvent this limitation are error-prone, as we discuss in this section.

Also, storage-related features aren't available: specifying the storage size — especially, specifying that the access type has a storage size of zero — isn't possible.

Missing features

Let's see a code example that shows some of the features that aren't available for anonymous access-to-object types:

    
    
    
        
with Ada.Unchecked_Deallocation; package Missing_Features is -- We cannot specify which pool will be used -- in the anonymous access-to-object -- allocation; the pool is selected by the -- compiler: IA : access Integer := new Integer; -- -- All the features below aren't available -- for an anonymous access-to-object: -- -- Having a specific storage pool associated -- with the access type: type String_Access is access String; -- Automatically creates -- String_Access'Storage_Pool type Integer_Access is access Integer with Storage_Pool => String_Access'Storage_Pool; -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Using the pool from another -- access type. -- Specifying a deallocation function for the -- access type: procedure Free is new Ada.Unchecked_Deallocation (Object => Integer, Name => Integer_Access); -- Specifying a limited storage size for -- the access type: type Integer_Access_Store_128 is access Integer with Storage_Size => 128; -- Limiting the storage size for the -- access type to zero: type Integer_Access_Store_0 is access Integer with Storage_Size => 0; end Missing_Features;

In the Missing_Features package, we see some of the features that we cannot use for the anonymous access Integer type, but that are available for equivalent named access types:

  • There's no specific memory pool associated with the access object IA. In contrast, named types — such as String_Access and Integer_Access — have an associated pool, and we can use the Storage_Pool aspect and the Storage_Pool attribute to customize them.

  • We cannot instantiate the Ada.Unchecked_Deallocation procedure for the access Integer type. However, we can instantiate it for named access types such as the Integer_Access type.

  • We cannot use the Storage_Size attribute for the access Integer type, but we're allowed to use it with named access types, which we do in the declaration of the Integer_Access_Store_128 and Integer_Access_Store_0 types.

Dangerous memory deallocation

We might think that we could make up for the absence of the Ada.Unchecked_Deallocation procedure for anonymous access-to-object types by converting those access objects (of anonymous access types) to a named type that has the same designated subtype. For example, if we have an access object IA of an anonymous access Integer type, we can convert it to the named Integer_Access type, provided this named access type is compatible with the anonymous access type, e.g.:

type Integer_Access is access all Integer

Let's see a complete code example:

    
    
    
        
with Ada.Unchecked_Deallocation; procedure Show_Dangerous_Deallocation is type Integer_Access is access all Integer; procedure Free is new Ada.Unchecked_Deallocation (Object => Integer, Name => Integer_Access); IA : access Integer; begin IA := new Integer; IA.all := 30; -- Potentially erroneous deallocation via type -- conversion: Free (Integer_Access (IA)); end Show_Dangerous_Deallocation;

This example declares the IA access object of the anonymous access Integer type. After allocating an object for IA via new, we try to deallocate it by first converting it to the Integer_Access type, so that we can call the Free procedure to actually deallocate the object. Although this code compiles, it'll only work if both access Integer and Integer_Access types are using the same memory pool. Since we cannot really determine this, the result is potentially erroneous: it'll work if the compiler selected the same pool, but it'll fail otherwise.

Important

Because allocating memory for anonymous access types is potentially dangerous, we can use the No_Anonymous_Allocators restriction — which is available since Ada 2012 — to prevent this kind of memory allocation being used in the code. For example:

    
    
    
        
pragma Restrictions (No_Anonymous_Allocators); procedure Show_Dangerous_Allocation is IA : access Integer; begin IA := new Integer; IA.all := 30; end Show_Dangerous_Allocation;

Possible solution using named access types

A better solution to avoid issues when allocating and deallocating memory for anonymous access-to-object types is to allocate the object using a known pool. As mentioned before, the memory pool associated with a named access type is well-defined, so we can use this kind of types for memory allocation. In fact, we can use a named memory type to allocate an object via new, and then associate this allocated object with the access object of anonymous access type.

Let's see a code example:

    
    
    
        
with Ada.Unchecked_Deallocation; procedure Show_Successful_Deallocation is type Integer_Access is access Integer; procedure Free is new Ada.Unchecked_Deallocation (Object => Integer, Name => Integer_Access); IA : access Integer; Typed_IA : Integer_Access; begin Typed_IA := new Integer; IA := Typed_IA; IA.all := 30; -- Deallocation of the access object that has -- an associated type: Free (Typed_IA); end Show_Successful_Deallocation;

In this example, all operations related to memory allocation are exclusively making use of the Integer_Access type, which is a named access type. In fact, new Integer allocates the object from the pool associated with the Integer_Access type, and the call to Free deallocates this object back into that pool. Therefore, associating this object with the IA access object — in the IA := Typed_IA assignment — doesn't creates problems afterwards in the object's deallocation. (When calling Free, we only refer to the object of named access type, so the object is deallocated from a known pool.)

Of course, a potential issue here is that IA becomes a dangling reference after the call to Free. Therefore, we can improve this solution by completely hiding the memory allocation and deallocation for the anonymous access types in subprograms — e.g. as part of a package. By doing so, we don't expose the named access type, thereby reducing the possibility of dangling references.

In fact, we can generalize this approach with the following (generic) package:

    
    
    
        
generic type T is private; package Hidden_Anonymous_Allocation is function New_T return not null access T; procedure Free (Obj : access T); end Hidden_Anonymous_Allocation;
with Ada.Unchecked_Deallocation; package body Hidden_Anonymous_Allocation is type T_Access is access all T; procedure T_Access_Free is new Ada.Unchecked_Deallocation (Object => T, Name => T_Access); function New_T return not null access T is begin return T_Access'(new T); -- Using allocation of the T_Access type: -- object is allocated from T_Access's pool end New_T; procedure Free (Obj : access T) is Tmp : T_Access := T_Access (Obj); begin T_Access_Free (Tmp); -- Using deallocation procedure of the -- T_Access type end Free; end Hidden_Anonymous_Allocation;

In the generic Hidden_Anonymous_Allocation package, New_T allocates a new object internally and returns an anonymous access to this object. The Free procedure deallocates this object.

In the body of the Hidden_Anonymous_Allocation package, we use the named access type T_Access to handle the actual memory allocation and deallocation. As expected, because those operations happen on the pool associated with the T_Access type, we don't have to worry about potential deallocation issues.

Finally, we can instantiate this package for the type we want to have anonymous access types for, say a type named Rec. Then, when using the Rec type in the main subprogram, we can simply call the corresponding subprograms for memory allocation and deallocation. For example:

    
    
    
        
with Hidden_Anonymous_Allocation; package Info is type Rec is private; function New_Rec return not null access Rec; procedure Free (Obj : access Rec); private type Rec is record I : Integer; end record; package Rec_Allocation is new Hidden_Anonymous_Allocation (T => Rec); function New_Rec return not null access Rec renames Rec_Allocation.New_T; procedure Free (Obj : access Rec) renames Rec_Allocation.Free; end Info;
with Info; use Info; procedure Show_Info_Allocation_Deallocation is RA : constant not null access Rec := New_Rec; begin Free (RA); end Show_Info_Allocation_Deallocation;

In this example, we instantiate the Hidden_Anonymous_Allocation package in the Info package, which also defines the Rec type. We associate the New_T and Free subprograms with the Rec type by using subprogram renaming. Finally, in the Show_Info_Allocation_Deallocation procedure, we use these subprograms to allocate and deallocate the type.

Possible solution using the stack

Another approach that we could consider to avoid memory deallocation issues for anonymous access-to-object types is by simply using the stack for the object creation. For example:

    
    
    
        
procedure Show_Automatic_Deallocation is I : aliased Integer; -- ^ Allocating object on the stack IA : access Integer; begin IA := I'Access; -- Indirect allocation: -- object creation on the stack. IA.all := 30; -- Automatic deallocation at the end of the -- procedure because the integer variable is -- on the stack. end Show_Automatic_Deallocation;

In this case, we create the I object on the stack by simply declaring it. Then, we get access to it and assign it to the IA access object.

With this approach, we're indirectly allocating an object for an anonymous access type by creating it on the stack. Also, because we know that the I is automatically deallocated when it gets out of scope, we don't have to worry about explicitly deallocating the object referred by IA.

When to use anonymous access-to-objects types

In summary, anonymous access-to-object types have many drawbacks that often outweigh their benefits. In fact, allocation for those types can quickly become very complicated. Therefore, in general, they're not a good alternative to named access types. Indeed, the difficulties that we've just seen might make them a much worse option than just using named access types instead.

We might consider using anonymous access-to-objects types only in cases when we reach a point in our implementation work where using named access types becomes impossible — or when using them becomes even more complicated than equivalent solutions using anonymous access types. This scenario, however, is usually the exception rather than the rule. Thus, as a general guideline, we should always aim to use named access types.

That being said, an important exception to this advice is when we're interfacing to other languages. In this case, as we'll discuss later, using anonymous access-to-objects types can be significantly simpler (compared to named access types) without the drawbacks that we've just discussed.

Access discriminants

Previously, we've discussed discriminants as access values. In that section, we only used named access types. Now, in this section, we see how to use anonymous access types as discriminants. This feature is also known as access discriminants and it provides some flexibility that can be interesting in terms of software design, as we'll discuss later.

Let's start with an example:

    
    
    
        
package Custom_Recs is -- Declaring a discriminant with an anonymous -- access type: type Rec (IA : access Integer) is record I : Integer := IA.all; end record; procedure Show (R : Rec); end Custom_Recs;
with Ada.Text_IO; use Ada.Text_IO; package body Custom_Recs is procedure Show (R : Rec) is begin Put_Line ("R.IA = " & Integer'Image (R.IA.all)); Put_Line ("R.I = " & Integer'Image (R.I)); end Show; end Custom_Recs;
with Custom_Recs; use Custom_Recs; procedure Show_Access_Discriminants is I : aliased Integer := 10; R : Rec (I'Access); begin Show (R); I := 20; R.I := 30; Show (R); end Show_Access_Discriminants;

In this example, we use an anonymous access type for the discriminant in the declaration of the Rec type of the Custom_Recs package. In the Show_Access_Discriminants procedure, we declare R and provide access to the local I integer.

Similarly, we can use unconstrained designated subtypes:

    
    
    
        
package Persons is -- Declaring a discriminant with an anonymous -- access type whose designated subtype is -- unconstrained: type Person (Name : access String) is record Age : Integer; end record; procedure Show (P : Person); end Persons;
with Ada.Text_IO; use Ada.Text_IO; package body Persons is procedure Show (P : Person) is begin Put_Line ("Name = " & P.Name.all); Put_Line ("Age = " & Integer'Image (P.Age)); end Show; end Persons;
with Persons; use Persons; procedure Show_Person is S : aliased String := "John"; P : Person (S'Access); begin P.Age := 30; Show (P); end Show_Person;

In this example, for the discriminant of the Person type, we use an anonymous access type whose designated subtype is unconstrained. In the Show_Person procedure, we declare the P object and provide access to the S string.

Default Value of Access Discriminants

In contrast to named access types, we cannot use a default value for the access discriminant of a non-limited type:

    
    
    
        
package Custom_Recs is -- Declaring a discriminant with an anonymous -- access type and a default value: type Rec (IA : access Integer := new Integer'(0)) is record I : Integer := IA.all; end record; end Custom_Recs;

However, if we change the type declaration to be a limited type, having a default value for the access discriminant is OK:

    
    
    
        
package Custom_Recs is -- Declaring a discriminant with an anonymous -- access type and a default value: type Rec (IA : access Integer := new Integer'(0)) is limited record I : Integer := IA.all; end record; procedure Show (R : Rec); end Custom_Recs;
with Ada.Text_IO; use Ada.Text_IO; package body Custom_Recs is procedure Show (R : Rec) is begin Put_Line ("R.IA = " & Integer'Image (R.IA.all)); Put_Line ("R.I = " & Integer'Image (R.I)); end Show; end Custom_Recs;

Note that, if we don't provide a value for the access discriminant when declaring an object R, the default value is allocated (via new) during R's creation.

    
    
    
        
with Custom_Recs; use Custom_Recs; procedure Show_Access_Discriminants is R : Rec; -- ^^^ -- This triggers "new Integer'(0)", so an -- integer object is allocated and stored in -- the R.IA discriminant. begin Show (R); -- R gets out of scope here, and the object -- allocated via new hasn't been deallocated. end Show_Access_Discriminants;

In this case, the allocated object won't be deallocated when R gets out of scope!

Benefits of Access Discriminants

Access discriminants have the same benefits that we've already seen earlier while discussing discriminants as access values. An additional benefit is its extended flexibility: access discriminants are compatible with any access T'Access, as long as T is of the designated subtype.

Consider the following example using the named access type Access_String:

    
    
    
        
package Persons is type Access_String is access all String; -- Declaring a discriminant with a named -- access type: type Person (Name : Access_String) is record Age : Integer; end record; procedure Show (P : Person); end Persons;
with Ada.Text_IO; use Ada.Text_IO; package body Persons is procedure Show (P : Person) is begin Put_Line ("Name = " & P.Name.all); Put_Line ("Age = " & Integer'Image (P.Age)); end Show; end Persons;
with Persons; use Persons; procedure Show_Person is S : aliased String := "John"; P : Person (S'Access); -- ^^^^^^^^ ERROR: cannot use local -- object -- -- We can, however, allocate the string via -- new: -- -- S : Access_String := new String'("John"); -- P : Person (S); begin P.Age := 30; Show (P); end Show_Person;

This code doesn't compile because we cannot have a non-local pointer (Access_String) pointing to the local object S. The only way to make this work is by allocating the string via new (i.e.: S : Access_String := new String).

However, if we use an access discriminant in the declaration of Person, the code compiles fine:

    
    
    
        
package Persons is -- Declaring a discriminant with an anonymous -- access type: type Person (Name : access String) is record Age : Integer; end record; procedure Show (P : Person); end Persons;
with Persons; use Persons; procedure Show_Person is S : aliased String := "John"; P : Person (S'Access); -- ^^^^^^^^ OK -- Allocating the string via new and using it -- in P's declaration is OK as well, but we -- should manually deallocate it before S -- gets out of scope: -- -- S : access String := new String'("John"); -- P : Person (S); begin P.Age := 30; Show (P); end Show_Person;

In this case, getting access to the local object S and using it for P's discriminant is perfectly fine.

Preventing dangling pointers

Note that the usual rules that prevent dangling pointers still apply here. This ensures that we can safely use access discriminants. For example:

    
    
    
        
with Persons; use Persons; procedure Show_Person is function Local_Init return Person is S : aliased String := "John"; begin return (Name => S'Access, Age => 30); -- ^^^^^^^^^^^^^^^^ -- ERROR: dangling reference! end Local_Init; P : Person := Local_Init; begin Show (P); end Show_Person;

In this example, compilation fails in the Local_Init function when trying to return an object of Person type because S'Access would be a dangling reference.

Self-reference

Previously, we've seen that we can declare self-references using named access types. We can do the same with anonymous access types. Let's revisit the code example that implements linked lists:

    
    
    
        
generic type T is private; package Linked_Lists is type List is limited private; procedure Append_Front (L : in out List; E : T); procedure Append_Rear (L : in out List; E : T); procedure Show (L : List); private type Component is record Next : access Component; -- ^^^^^^^^^^^^^^^^ -- Self-reference -- -- (Note that we haven't finished the -- declaration of the "Component" type -- yet, but we're already referring to -- it.) Value : T; end record; type List is access all Component; end Linked_Lists;
pragma Ada_2022; with Ada.Text_IO; use Ada.Text_IO; package body Linked_Lists is procedure Append_Front (L : in out List; E : T) is New_First : constant List := new Component'(Value => E, Next => L); begin L := New_First; end Append_Front; procedure Append_Rear (L : in out List; E : T) is New_Last : constant List := new Component'(Value => E, Next => null); begin if L = null then L := New_Last; else declare Last : List := L; begin while Last.Next /= null loop Last := List (Last.Next); -- ^^^^ -- type conversion: -- "access Component" to -- "List" end loop; Last.Next := New_Last; end; end if; end Append_Rear; procedure Show (L : List) is Curr : List := L; begin if L = null then Put_Line ("[ ]"); else Put ("["); loop Put (Curr.Value'Image); Put (" "); exit when Curr.Next = null; Curr := Curr.Next; end loop; Put_Line ("]"); end if; end Show; end Linked_Lists;
with Linked_Lists; procedure Test_Linked_List is package Integer_Lists is new Linked_Lists (T => Integer); use Integer_Lists; L : List; begin Append_Front (L, 3); Append_Rear (L, 4); Append_Rear (L, 5); Append_Front (L, 2); Append_Front (L, 1); Append_Rear (L, 6); Append_Rear (L, 7); Show (L); end Test_Linked_List;

Here, in the declaration of the Component type (in the private part of the generic Linked_Lists package), we declare Next as an anonymous access type that refers to the Component type. (Note that at this point, we haven't finished the declaration of the Component type yet, but we're already using it as the designated subtype of an anonymous access type.) Then, we declare List as a general access type (with Component as the designated subtype).

It's worth mentioning that the List type and the anonymous access Component type aren't the same type, although they share the same designated subtype. Therefore, in the implementation of the Append_Rear procedure, we have to use type conversion to convert from the anonymous access Component type to the (named) List type.

Mutually dependent types using anonymous access types

In the section on mutually dependent types using access types, we've seen a code example that was using named access types. We could now rewrite it using anonymous access types:

    
    
    
        
package Mutually_Dependent is type T2; type T1 is record B : access T2; end record; type T2 is record A : access T1; end record; end Mutually_Dependent;

In this example, T1 and T2 are mutually dependent types. We're using anonymous access types in the declaration of the B and A components.

Access parameters

In the previous chapter, we talked about parameters as access values. As you might have expected, we can also use anonymous access types as parameters of a subprogram. However, they're limited to be in parameters of a subprogram or return type of a function (also called the access result type):

    
    
    
        
package Names is function Init (S1, S2 : String) return access String; -- ^^^^^^^^^^^^^^^^^^^^ -- Anonymous access type as the access -- result type. procedure Show (N : access constant String); -- ^^^^^^^^^^^^^^^^^^^^^^ -- Anonymous access type as a parameter type. end Names;

In this example, we have a string as the access result type of the Init function, and another string as the access parameter of the Show procedure.

This is the complete code example:

    
    
    
        
package Names is function Init (S1, S2 : String) return access String; procedure Show (N : access constant String); private function Init (S1, S2 : String) return access String is (new String'(S1 & "-" & S2)); end Names;
with Ada.Text_IO; use Ada.Text_IO; package body Names is procedure Show (N : access constant String) is begin Put_Line ("Name: " & N.all); end Show; end Names;
with Names; use Names; procedure Show_Names is N : access String := Init ("Lily", "Ann"); begin Show (N); end Show_Names;

Note that we're not using the in parameter mode in the Show procedure above. Usually, this parameter mode can be omitted, as it is the default parameter mode — procedure P (I : Integer) is the same as procedure P (I : in Integer). However, in the case of the Show procedure, the in parameter mode isn't just optionally absent. In fact, for access parameters, the parameter mode is always implied as in, so writing it explicitly is actually forbidden. In other words, we can only write N : access String or N : access constant String, but we cannot write N : in access String or N : in access constant String.

For further reading...

When we discussed parameters as access values in the previous chapter, we saw how we can simply use different parameter modes to write a program instead of using access types. Basically, to implement the same functionality, we just replaced the access types by selecting the correct parameter modes instead and used simpler data types.

Let's do the same exercise again, this time by adapting the previous code example with anonymous access types:

    
    
    
        
package Names is function Init (S1, S2 : String) return String; procedure Show (N : String); private function Init (S1, S2 : String) return String is (S1 & "-" & S2); end Names;
with Ada.Text_IO; use Ada.Text_IO; package body Names is procedure Show (N : String) is begin Put_Line ("Name: " & N); end Show; end Names;
with Names; use Names; procedure Show_Names is N : String := Init ("Lily", "Ann"); begin Show (N); end Show_Names;

Although we're using simple strings instead of access types in this version of the code example, we're still getting a similar behavior. However, there is a small, yet important difference in the way the string returned by Init is being allocated: while the previous implementation (which was using an access result type) was allocating the string on the heap, we're now allocating the string on the stack.

Later on, we talk about the accessibility rules in the case of access parameters.

In general, we should avoid access parameters whenever possible and simply use objects and parameter modes directly, as it makes the design simpler and less error-prone. One exception is when we're interfacing to other languages, especially C: this is our next topic. Another time when access parameters are vital is for inherited primitive operations for tagged types. We discuss this later on.

In the Ada Reference Manual

Interfacing To Other Languages

We can use access parameters to interface to other languages. This can be particularly useful when interfacing to C code that makes use of pointers. For example, let's assume we want to call the add_one function below in our Ada implementation:

    
    
    
        
void add_one(int *p_i);
void add_one(int *p_i) { *p_i = *p_i + 1; }

We could map the int * parameter of add_one to access Integer in the Ada specification:

procedure Add_One (IA : access Integer)
  with Import, Convention => C;

This is a complete code example:

    
    
    
        
package Operations is procedure Add_One (IA : access Integer) with Import, Convention => C; end Operations;
with Ada.Text_IO; use Ada.Text_IO; with Operations; use Operations; procedure Show_Operations is I : aliased Integer := 42; begin Put_Line (I'Image); Add_One (I'Access); Put_Line (I'Image); end Show_Operations;

Once again, we can replace access parameters with simpler types by using the appropriate parameter mode. In this case, we could replace access Integer by aliased in out Integer. This is the modified version of the code:

    
    
    
        
package Operations is procedure Add_One (IA : aliased in out Integer) with Import, Convention => C; end Operations;
with Ada.Text_IO; use Ada.Text_IO; with Operations; use Operations; procedure Show_Operations is I : aliased Integer := 42; begin Put_Line (I'Image); Add_One (I); Put_Line (I'Image); end Show_Operations;

However, there are situations where aliased objects cannot be used. For example, suppose we want to allocate memory inside a C function. In this case, the pointer to that memory block must be mapped to an access type in Ada.

Let's extend the previous C code example and introduce the alloc_integer and dealloc_integer functions, which allocate and deallocate an integer value:

    
    
    
        
int * alloc_integer(); void dealloc_integer(int *p_i); void add_one(int *p_i);
#include <stdlib.h> int * alloc_integer() { return malloc(sizeof(int)); } void dealloc_integer(int *p_i) { free (p_i); } void add_one(int *p_i) { *p_i = *p_i + 1; }

In this case, we really have to use access types to interface to these C functions. In fact, we need an access result type to interface to the alloc_integer() function, and an access parameter in the case of the dealloc_integer() function. This is the corresponding specification in Ada:

    
    
    
        
package Operations is function Alloc_Integer return access Integer with Import, Convention => C; procedure Dealloc_Integer (IA : access Integer) with Import, Convention => C; procedure Add_One (IA : aliased in out Integer) with Import, Convention => C; end Operations;

Note that we're still using an aliased integer type for the Add_One procedure, while we're using access types for the other two subprograms.

Finally, as expected, we can use this specification in a test application:

    
    
    
        
with Ada.Text_IO; use Ada.Text_IO; with Operations; use Operations; procedure Show_Operations is I : access Integer := Alloc_Integer; begin I.all := 42; Put_Line (I.all'Image); Add_One (I.all); Put_Line (I.all'Image); Dealloc_Integer (I); end Show_Operations;

In this application, we get a C pointer from the alloc_integer function and encapsulate it in an Ada access type, which we then assign to I. In the last line of the procedure, we call Dealloc_Integer and pass I to it, which deallocates the memory block indicated by the C pointer.

In the Ada Reference Manual

Inherited Primitive Operations For Tagged Types

In order to declare inherited primitive operations for tagged types that use access types, we need to use access parameters. The reason is that, to be a primitive operation for some tagged type — and hence inheritable — the subprogram must reference the tagged type name directly in the parameter profile. This means that a named access type won't suffice, because only the access type name would appear in the profile. For example:

    
    
    
        
package Inherited_Primitives is type T is tagged private; type T_Access is access all T; procedure Proc (N : T_Access); -- Proc is not a primitive of type T. type T_Child is new T with private; type T_Child_Access is access all T_Child; private type T is tagged null record; type T_Child is new T with null record; end Inherited_Primitives;
with Ada.Text_IO; use Ada.Text_IO; package body Inherited_Primitives is procedure Proc (N : T_Access) is null; end Inherited_Primitives;
with Inherited_Primitives; use Inherited_Primitives; procedure Show_Inherited_Primitives is Obj : T_Access := new T; Obj_Child : T_Child_Access := new T_Child; begin Proc (Obj); Proc (Obj_Child); -- ^^^^^^^^^ -- ERROR: Proc is not inherited! end Show_Inherited_Primitives;

In this example, Proc is not a primitive of type T because it's referring to type T_Access, not type T. This means that Proc isn't inherited when we derive the T_Child type. Therefore, when we call Proc (Obj_Child), a compilation error occurs because the compiler expects type T_Access — there's no Proc (N : T_Child_Access) that could be used here.

If we replace T_Access in the Proc procedure with an an access parameter (access T), the subprogram becomes a primitive of T:

    
    
    
        
package Inherited_Primitives is type T is tagged private; procedure Proc (N : access T); -- Proc is a primitive of type T. type T_Child is new T with private; private type T is tagged null record; type T_Child is new T with null record; end Inherited_Primitives;
package body Inherited_Primitives is procedure Proc (N : access T) is null; end Inherited_Primitives;
with Inherited_Primitives; use Inherited_Primitives; procedure Show_Inherited_Primitives is Obj : access T := new T; Obj_Child : access T_Child := new T_Child; begin Proc (Obj); Proc (Obj_Child); -- ^^^^^^^^^ -- OK: Proc is inherited! end Show_Inherited_Primitives;

Now, the child type T_Child (derived from the T) inherits the primitive operation Proc. This inherited operation has an access parameter designating the child type:

type T_Child is new T with private;

procedure Proc (N : access T_Child);
--  Implicitly inherited primitive operation

In the Ada Reference Manual

User-Defined References

Implicit dereferencing isn't limited to the contexts that Ada supports by default: we can also add implicit dereferencing to our own types by using the Implicit_Dereference aspect.

To do this, we have to declare:

  • a reference type, where we use the Implicit_Dereference aspect to specify the reference discriminant, which is the record discriminant that will be dereferenced; and

  • a reference object, which contains an access value that will be dereferenced.

Also, for the reference type, we have to:

  • specify the reference discriminant as an access discriminant; and

  • indicate the name of the reference discriminant when specifying the Implicit_Dereference aspect.

Let's see a simple example:

    
    
    
        
with Ada.Text_IO; use Ada.Text_IO; procedure Show_User_Defined_Reference is type Id_Number is record Id : Positive; end record; -- -- Reference type: -- type Id_Ref (Ref : access Id_Number) is -- ^ reference discriminant null record with Implicit_Dereference => Ref; -- ^^^ -- name of the reference -- discriminant -- -- Access value: -- I : constant access Id_Number := new Id_Number'(Id => 42); -- -- Reference object: -- R : Id_Ref (I); begin Put_Line ("ID: " & Positive'Image (R.Id)); -- ^ Equivalent to: -- R.Ref.Id -- or: -- R.Ref.all.Id end Show_User_Defined_Reference;

Here, we declare a simple record type (Id_Number) and a corresponding reference type (Id_Ref). Note that:

  • the reference discriminant Ref has an access to the Id_Number type; and

  • we indicate this reference discriminant in the Implicit_Dereference aspect.

Then, we declare an access value (the I constant) and use it for the Ref discriminant in the declaration of the reference object R.

Finally, we implicitly dereference R and access the Id component by simply writing R.Id — instead of the extended forms R.Ref.Id or R.Ref.all.Id.

Important

The extended form mentioned in the example that we just saw (R.Ref.all.Id) makes it clear that two steps happen when evaluating R.Id:

  • First, R.Ref is implied from R because of the Implicit_Dereference aspect.

  • Then, R.Ref is implicitly dereferenced to R.Ref.all.

After these two steps, we can access the actual object. (In our case, we can access the Id component.)

Note that we cannot use access types directly for the reference discriminant. For example, if we made the following change in the previous code example, it wouldn't compile:

type Id_Number_Access is access Id_Number;

--  Reference type:
type Id_Ref (Ref : Id_Number_Access) is
--                 ^ ERROR: it must be
--                          an access
--                          discriminant!
  null record
    with Implicit_Dereference => Ref;

However, we could use other forms — such as not null access — in the reference discriminant:

--  Reference type:
type Id_Ref (Ref : not null access Id_Number) is
  null record
    with Implicit_Dereference => Ref;

In the Ada Reference Manual

Dereferencing of tagged types

Naturally, implicit dereferencing is also possible when calling primitives of a tagged type. For example, let's change the declaration of the Id_Number type from the previous code example and add a Show primitive.

    
    
    
        
package Info is type Id_Number (Id : Positive) is tagged private; procedure Show (R : Id_Number); private type Id_Number (Id : Positive) is tagged null record; end Info;
with Ada.Text_IO; use Ada.Text_IO; package body Info is procedure Show (R : Id_Number) is begin Put_Line ("ID: " & Positive'Image (R.Id)); end Show; end Info;

Then, let's declare a reference type and a reference object in the test application:

    
    
    
        
with Info; use Info; procedure Show_User_Defined_Reference is -- Reference type: type Id_Ref (Ref : access Id_Number) is null record with Implicit_Dereference => Ref; -- Access value: I : constant access Id_Number := new Id_Number (42); -- Reference object: R : Id_Ref (I); begin R.Show; -- Equivalent to: -- R.Ref.all.Show; end Show_User_Defined_Reference;

Here, we can call the Show procedure by simply writing R.Show instead of R.Ref.all.Show.

Simple container

A typical application of user-defined references is to create cursors when iterating over a container. As an example, let's implement the National_Date_Info package to store the national day of a country:

    
    
    
        
package National_Date_Info is subtype Country_Code is String (1 .. 3); type Time is record Year : Integer; Month : Positive range 1 .. 12; Day : Positive range 1 .. 31; end record; type National_Date is tagged record Country : Country_Code; Date : Time; end record; type National_Date_Access is access National_Date; procedure Show (Nat_Date : National_Date); end National_Date_Info;
with Ada.Text_IO; use Ada.Text_IO; package body National_Date_Info is procedure Show (Nat_Date : National_Date) is begin Put_Line ("Country: " & Nat_Date.Country); Put_Line ("Year: " & Integer'Image (Nat_Date.Date.Year)); end Show; end National_Date_Info;

Here, National_Date is a record type that we use to store the national day information. We can call the Show procedure to display this information.

Now, let's implement the National_Date_Containers with a container for national days:

    
    
    
        
with National_Date_Info; use National_Date_Info; package National_Date_Containers is -- Reference type: type National_Date_Reference (Ref : access National_Date) is tagged limited null record with Implicit_Dereference => Ref; -- Container (as an array): type National_Dates is array (Positive range <>) of National_Date_Access; -- The Find function scans the container to -- find a specific country, which is returned -- as a reference object. function Find (Nat_Dates : National_Dates; Country : Country_Code) return National_Date_Reference; end National_Date_Containers;
package body National_Date_Containers is function Find (Nat_Dates : National_Dates; Country : Country_Code) return National_Date_Reference is begin for I in Nat_Dates'Range loop if Nat_Dates (I).Country = Country then return National_Date_Reference'( Ref => Nat_Dates (I)); -- ^^^^^^^^^^^^^^^^^^^^^^^^^ -- Returning reference object with a -- reference to the national day we -- found. end if; end loop; return National_Date_Reference'(Ref => null); -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Returning reference object with a null -- reference in case the country wasn't -- found. This will trigger an exception -- if we try to dereference it. end Find; end National_Date_Containers;

Package National_Date_Containers contains the National_Dates type, which is an array type for declaring containers that we use to store the national day information. We can also see the declaration of the National_Date_Reference type, which is the reference type returned by the Find function when looking for a specific country in the container.

Important

We're declaring the container type (National_Dates) as an array type just to simplify the code. In many cases, however, this approach isn't recommended! Instead, we should use a private type in order to encapsulate — and better protect — the information stored in the actual container.

Finally, let's see a test application that stores information for some countries into the Nat_Dates container and displays the information for a specific country:

    
    
    
        
with National_Date_Info; use National_Date_Info; with National_Date_Containers; use National_Date_Containers; procedure Show_National_Dates is Nat_Dates : constant National_Dates (1 .. 5) := (new National_Date'("USA", Time'(1776, 7, 4)), new National_Date'("FRA", Time'(1789, 7, 14)), new National_Date'("DEU", Time'(1990, 10, 3)), new National_Date'("SPA", Time'(1492, 10, 12)), new National_Date'("BRA", Time'(1822, 9, 7))); begin Find (Nat_Dates, "FRA").Show; -- ^ implicit dereference end Show_National_Dates;

Here, we call the Find function to retrieve a reference object, whose reference (access value) has the national day information of France. We then implicitly dereference it to get the tagged object (of National_Date type) and display its information by calling the Show procedure.

Relevant topics

The National_Date_Containers package was implemented specifically as an accompanying package for the National_Date_Info package. It is possible, however, to generalize it, so that we can reuse the container for other record types. In fact, this is actually very straightforward:

    
    
    
        
generic type T is private; type T_Access is access T; type T_Cmp is private; with function Matches (E : T_Access; Elem : T_Cmp) return Boolean; package Generic_Containers is type Ref_Type (Ref : access T) is tagged limited null record with Implicit_Dereference => Ref; type Container is array (Positive range <>) of T_Access; function Find (Cont : Container; Elem : T_Cmp) return Ref_Type; end Generic_Containers;
package body Generic_Containers is function Find (Cont : Container; Elem : T_Cmp) return Ref_Type is begin for I in Cont'Range loop if Matches (Cont (I), Elem) then return Ref_Type'(Ref => Cont (I)); end if; end loop; return Ref_Type'(Ref => null); end Find; end Generic_Containers;

When comparing the Generic_Containers package to the National_Date_Containers package, we see that the main difference is the addition of the Matches function, which indicates whether the current element we're evaluating in the for-loop of the Find function is the one we're looking for.

In the main application, we can implement the Matches function and declare the National_Date_Containers package as an instance of the Generic_Containers package:

    
    
    
        
with Generic_Containers; with National_Date_Info; use National_Date_Info; procedure Show_National_Dates is function Matches_Country (E : National_Date_Access; Elem : Country_Code) return Boolean is (E.Country = Elem); package National_Date_Containers is new Generic_Containers (T => National_Date, T_Access => National_Date_Access, T_Cmp => Country_Code, Matches => Matches_Country); use National_Date_Containers; subtype National_Dates is Container; Nat_Dates : constant National_Dates (1 .. 5) := (new National_Date'("USA", Time'(1776, 7, 4)), new National_Date'("FRA", Time'(1789, 7, 14)), new National_Date'("DEU", Time'(1990, 10, 3)), new National_Date'("SPA", Time'(1492, 10, 12)), new National_Date'("BRA", Time'(1822, 9, 7))); begin Find (Nat_Dates, "FRA").Show; end Show_National_Dates;

Here, we instantiate the Generic_Containers package with the Matches_Country function, which is an expression function that compares the country component of the current National_Date reference with the name of the country we desire to learn about.

This generalized approach is actually used for the standard containers from the Ada.Containers packages. For example, the Ada.Containers.Vectors is specified as follows:

with Ada.Iterator_Interfaces;

generic
   type Index_Type is range <>;
   type Element_Type is private;
   with function "=" (Left, Right : Element_Type)
                      return Boolean is <>;
package Ada.Containers.Vectors
  with Preelaborate, Remote_Types,
       Nonblocking,
       Global => in out synchronized is

   -- OMITTED

   type Reference_Type
     (Element : not null access Element_Type) is
       private
         with Implicit_Dereference => Element,
              Nonblocking,
              Global => in out synchronized,
              Default_Initial_Condition =>
                (raise Program_Error);

   -- OMITTED

   function Reference
     (Container : aliased in out Vector;
      Index     : in Index_Type)
      return Reference_Type
        with Pre  => Index in
                       First_Index (Container) ..
                       Last_Index (Container)
                     or else raise
                             Constraint_Error,
           Post =>
             Tampering_With_Cursors_Prohibited
               (Container),
           Nonblocking,
           Global => null,
           Use_Formal => null;

   -- OMITTED

   function Reference
     (Container : aliased in out Vector;
      Position  : in Cursor)
      return Reference_Type
        with Pre  => (Position /= No_Element
                      or else raise
                              Constraint_Error)
                      and then
                        (Has_Element
                          (Container, Position)
                         or else raise
                                 Program_Error),
           Post   =>
             Tampering_With_Cursors_Prohibited
               (Container),
           Nonblocking,
           Global => null,
           Use_Formal => null;

   -- OMITTED

end Ada.Containers.Vectors;

(Note that most parts of the Vectors package were omitted for clarity. Please refer to the Ada Reference Manual for the complete package specification.)

Here, we see that the Implicit_Dereference aspect is used in the declaration of Reference_Type, which is the reference type returned by the Reference functions for an index or a cursor.

Also, note that the Vectors package has a formal equality function (=) instead of the Matches function we were using in our Generic_Containers package. The purpose of the formal function, however, is basically the same.

In the Ada Reference Manual

Anonymous Access Types and Accessibility Rules

In general, the accessibility rules we've seen earlier also apply to anonymous access types. However, there are some subtle differences, which we discuss in this section.

Let's adapt the code example from that section to make use of anonymous access types:

    
    
    
        
package Library_Level is L0_AO : access Integer; L0_Var : aliased Integer; end Library_Level;
with Library_Level; use Library_Level; procedure Show_Library_Level is L1_Var : aliased Integer; L1_AO : access Integer; procedure Test is L2_AO : access Integer; L2_Var : aliased Integer; begin L1_AO := L2_Var'Access; -- ^^^^^^ -- ILLEGAL: L2 object to -- L1 access object L2_AO := L2_Var'Access; -- ^^^^^^ -- LEGAL: L2 object to -- L2 access object end Test; begin L0_AO := new Integer'(22); -- ^^^^^^^^^^^ -- LEGAL: L0 object to -- L0 access object L0_AO := L1_Var'Access; -- ^^^^^^ -- ILLEGAL: L1 object to -- L0 access object L1_AO := L0_Var'Access; -- ^^^^^^ -- LEGAL: L0 object to -- L1 access object L1_AO := L1_Var'Access; -- ^^^^^^ -- LEGAL: L1 object to -- L1 access object L0_AO := L1_AO; -- legal!! -- ^^^^^ -- LEGAL: L1 access object to -- L0 access object -- -- ILLEGAL: L1 object -- (L1_AO = L1_Var'Access) -- to -- L0 access object -- -- This is actually OK at compile time, -- but the accessibility check fails at -- runtime. Test; end Show_Library_Level;

As we see in the code, in general, most accessibility rules are the same as the ones we've discussed when using named access types. For example, an assignment such as L0_AO := L1_Var'Access is illegal because we're trying to assign to an access object of less deep level.

However, assignment such as L0_AO := L1_AO are possible now: we don't get a type mismatch — as we did with named access types — because both objects are of anonymous access types. Note that the accessibility level cannot be determined at compile time: L1_AO can hold an access value at library level (which would make the assignment legal) or at a deeper level. Therefore, the compiler introduces an accessibility check here.

However, the accessibility check used in L0_AO := L1_AO fails at runtime because the corresponding access value (L1_Var'Access) is of a deeper level than L0_AO, which is illegal. (If you comment out the L1_AO := L1_Var'Access assignment prior to the L0_AO := L1_AO assignment, this accessibility check doesn't fail anymore.)

Conversions between Anonymous and Named Access Types

In the previous sections, we've discussed accessibility rules for named and anonymous access types separately. In this section, we see that the same accessibility rules apply when mixing both flavors together and converting objects of anonymous to named access types.

Let's adapt parts of the previous code example and add anonymous access types to it:

    
    
    
        
package Library_Level is type L0_Integer_Access is access all Integer; L0_Var : aliased Integer; L0_IA : L0_Integer_Access; L0_AO : access Integer; end Library_Level;
with Library_Level; use Library_Level; procedure Show_Library_Level is type L1_Integer_Access is access all Integer; L1_IA : L1_Integer_Access; L1_AO : access Integer; L1_Var : aliased Integer; begin --------------------------------------- -- From named type to anonymous type --------------------------------------- L0_IA := new Integer'(22); L1_IA := new Integer'(42); L0_AO := L0_IA; -- ^^^^^ -- LEGAL: assignment from -- L0 access object (named type) -- to -- L0 access object -- (anonymous type) L0_AO := L1_IA; -- ^^^^^ -- ILLEGAL: assignment from -- L1 access object (named type) -- to -- L0 access object -- (anonymous type) L1_AO := L0_IA; -- ^^^^^ -- LEGAL: assignment from -- L0 access object (named type) -- to -- L1 access object -- (anonymous type) L1_AO := L1_IA; -- ^^^^^ -- LEGAL: assignment from -- L1 access object (named type) -- to -- L1 access object -- (anonymous type) --------------------------------------- -- From anonymous type to named type --------------------------------------- L0_AO := L0_Var'Access; L1_AO := L1_Var'Access; L0_IA := L0_Integer_Access (L0_AO); -- ^^^^^^^^^^^^^^^^^ -- LEGAL: conversion / assignment from -- L0 access object -- (anonymous type) -- to -- L0 access object (named type) L0_IA := L0_Integer_Access (L1_AO); -- ^^^^^^^^^^^^^^^^^ -- ILLEGAL: conversion / assignment from -- L1 access object -- (anonymous type) -- to -- L0 access object (named type) -- (accessibility check fails) L1_IA := L1_Integer_Access (L0_AO); -- ^^^^^^^^^^^^^^^^^ -- LEGAL: conversion / assignment from -- L0 access object -- (anonymous type) -- to -- L1 access object (named type) L1_IA := L1_Integer_Access (L1_AO); -- ^^^^^^^^^^^^^^^^^ -- LEGAL: conversion / assignment from -- L1 access object -- (anonymous type) -- to -- L1 access object (named type) end Show_Library_Level;