Programming CS2130 Language Concepts and Paradigms
Unit 8 General Access Types In CS1210 (DSA) access or pointer types were used to provide a means of manipulating objects created by an allocator (i.e. NEW). Such access types are referred to as pool-specific access types. Access types may also be used to provide indirect access to data objects declared in the normal way; these are known as general access types. For example we can declare a general access type such as
TYPE Int_Ptr IS ACCESS ALL Integer;
Note the use of ALL in the general access type declaration to distinguish it from a poolspecific access type. Without this the type Int_Ptr could only be used to refer to integers created by the allocator NEW. With the use of ALL, it may refer to any variable of Integer type provided that the variable is designated as ALIASED1:
I : ALIASED Integer; IP : Int_Ptr := I'ACCESS; .......... IP.ALL := 3; -- indirect assignment to I
It is also possible to restrict the indirect access to be 'read-only':
TYPE Const_Int_Ptr IS ACCESS CONSTANT Integer; CIP : Const_Int_Ptr; I : ALIASED Integer; C : ALIASED CONSTANT Integer := 10; .......... CIP := C'ACCESS; -- OK -- CIP points to C Put(CIP.ALL); -- output value of C CIP := I'ACCESS; Put(CIP.ALL); I := 20; CIP.ALL := 30; ----OK -- CIP now points to I output value of I OK to change I directly !? illegal as CIP is ACCESS CONSTANT
It is possible to alias variables of any Ada type including arrays or records. Below the whole array A can be aliased, but NOT its individual elements:
TYPE IntArray IS ARRAY(1 .. 100) OF Integer; TYPE Array_Ptr IS ACCESS ALL IntArray; A : ALIASED IntArray; A_Ptr : Array_Ptr := A'ACCESS; -- OK I_Ptr : Int_Ptr := A(1)'ACCESS; -- !? illegal
It is also possible to alias the components of an array
TYPE ArrayOfInt IS ARRAY(1 .. 100) OF ALIASED Integer; B : ArrayOfInt; ......... IP : Int_Ptr := B(2)'ACCESS; -- OK
Here the individual elements of B can be aliased, but not the whole array. Of course if we defined an array of type ArrayOfInt as ALIASED, we could access the whole of the array and its individual elements via suitably defined access types:
C : ALIASED ArrayOfInt; IP : Int_Ptr := C(10)'ACCESS;
1
-- OK
This is a warning to the reader of the program that the variable may be updated indirectly via an access type as well as via its name. It also tells the compiler not to perform certain optimisation for the aliased variable (such as maintaining it in a machine register rather than in RAM).
A Barnes, 2004 1 CS2130/Unit 8
TYPE Aliased_Array_Ptr IS ACCESS ArrayOfInt; AA_Ptr : Aliased_Array_Ptr := C'ACCESS; -- OK AB_Ptr : Aliased_Array_Ptr := B'ACCESS; -- illegal
It is also possible to access individual components of a record provided they are marked as aliased:
TYPE PersonRecord IS RECORD Name : String((1 ..20); Age : ALIASED Integer; A_Levels : Integer; END RECORD; P : PersonRecord; IP : Int_Ptr := P.Age'ACCESS; JP : Int_Ptr := P.A_Levels'ACCESS; -- OK -- !? illegal
Some Uses of Access Types The primary use of access types is undoubtedly for dynamic data structures such as linked lists and trees. This was considered in some detail in CS1210 (DSA) and will not be expanded upon here. As we shall see in later lectures access types are also much used in object-oriented programming in Ada. However access types have other uses; for example they provide an extra degree of flexibility in some situations. In Ada we cannot directly define an array of character strings of different lengths (often called a ragged array)
TYPE Ragged_Array IS ARRAY(1 .. 12) OF String; -- !? illegal TYPE FixLen_Array IS ARRAY(1 .. 12) OF String(1 .. 20); -- OK
The declaration of type Ragged_Array is illegal as the element type must be a constrained type and type String is unconstrained. We could use an array of type FixLen_Array (as long as our strings contain no more than 20 characters) provided that we pad out the strings to the full length with blanks. However we can solve the problem as follows:
TYPE String_Access IS ACCESS ALL String; TYPE Ragged_Array IS ARRAY(1 .. 12) OF String_Access;
Now we can write:
Month : Ragged_Array; S : ALIASED String := "January"; Month(1) := S'ACCESS; Month(2) := NEW String'("February"); .......
although from a stylistic point of view, we would not normally mix dynamically and statically allocated strings in the same ragged array. Now the array (in effect) holds strings of different lengths, but the strings can be manipulated normally
Month(2)(1) := 'f'; -- change first char of 2nd string Put(Month(2)(1 .. 4)) -- output first 4 chars of 2nd string Put_Line(Month(1).ALL); -- output all of first string Month(2) := NEW String'("fevrier");
Note only when we are referring to the string as a whole do we need to use .ALL to resolve the ambiguity by forcing the access value to be dereferenced. In all other cases the dereferencing of the access value is performed automatically. For example Month(2)(1) is really an abbreviation for Month(2).ALL(1) In Java (because of the reference semantics) it is straightforward to create ragged arrays:
A Barnes, 2004
2
CS2130/Unit 8
String[] month = {"January", "February", "March", "April, "May", "June", "July", "August", "September" "October", "November", "December"}
This defines month to be an array of 12 strings of varying lengths. Another situation in which access types are useful is when sorting arrays of some large composite data structure such as a record with many fields. All internal sorts involve a considerable amount of element swapping and hence a considerable amount of data copying, particularly if each data structure is large. The amount of data copying can be reduced substantially if pointers to the data are swapped. For example given
TYPE BigRecord IS RECORD Key : some-type; ..... -- many other fields END RECORD; TYPE RecPtr IS ACCESS ALL BigRecord; TYPE RecArray IS ARRAY(1 ..1000) OF ALIASED BigRecord; TYPE PtrArray IS ARRAY(1 ..1000) OF RecPtr; R : RecArray; P : PtrArray; ........... FOR I IN 1 .. 1000 LOOP P(I) := R(I)'ACCESS; -- set-up pointer to ith record END LOOP; ........ Sort(P); -- pass array of pointers to Sort procedure -- not the array of records itself
A suitable implementation (using a straight insertion algorithm as in ISP Unit 18) is
PROCEDURE Sort(ToSort : IN OUT PtrArray) IS NextValue : RecPtr; Pos : Positive; BEGIN FOR K IN 2 .. 1000 LOOP NextValue := ToSort(K); Pos := K; WHILE Pos > Low AND THEN ToSort(Pos-1).Key > NextValue.Key LOOP Pos := Pos - 1; END LOOP; IF Pos /= K THEN -- shift pointers not the records themselves ToSort(Pos+1 .. K) := ToSort(Pos .. K-1); ToSort(Pos) := NextValue; END IF; END LOOP; END Sort;
Note the code of Sort is virtually unchanged from that in which we pass the array of records itself to the Sort procedure; the only changes are:
PROCEDURE Sort(ToSort : IN OUT RecArray) IS NextValue : BigRecord; -- rest of code unchanged ......... Sort(R); -- pass the array of records itself
Dangling Pointers and Accessibility Rules Consider the following piece of C or C++ code:
A Barnes, 2004
3
CS2130/Unit 8
int* i_ptr; // declare a pointer variable i_ptr { int i; // declare local variable i in a block i_ptr = &i; // assign address of i to i_ptr *i_ptr = 0; // safe to dereference i_ptr here (assigns 0 to i) ........ } *i_ptr = 1; // legal but totally unsafe to dereference i_ptr here // (i no longer exists so we can't safely assign 1 to it)
The problem here is that outside the inner block i_ptr refers to storage for i which no longer exists. Such references are called dangling pointers. In C and C++ the compiler provides little or no protection against the creation of dangling pointers. In Ada there are accessibility rules that ensure that dangling pointers cannot be created in this way; in essence these state that the ACCESS attribute cannot be applied to an object whose lifetime is less than that of the associated access type.
PROCEDURE Main IS TYPE Int_Ptr IS ACCESS ALL Integer; Ref : Int_Ptr; BEGIN DECLARE I : ALIASED Integer; BEGIN Ref := I'ACCESS; -- (a) !? illegal ....... END; -- Ref would now be a dangling pointer Ref.ALL := 0; -- (b) ?? attempt indirect assignment to I which ....... -- no longer exists END Main;
These rules which refer to the lifetime of the access type rather than the access variable, are rather restrictive and the following is also illegal:
PROCEDURE Main IS TYPE Int_Ptr IS ACCESS ALL Integer; Ref1 : Int_Ptr; BEGIN DECLARE I : ALIASED Integer; Ref2 : Int_Ptr; BEGIN Ref2 := I'ACCESS; -- (c) !? also illegal ....... Ref1 := Ref2; -- (d) END; -- Ref1 is now a dangling pointer Ref1.ALL := 0; -- (e) ?? attempt indirect assignment to I ....... END Main;
Although the use of the ACCESS attribute at (c) does not itself cause problems as the lifetime of the pointer variable Ref2 is no greater than that of I ; the possibility remains of later assigning to a pointer variable of greater lifetime (e.g. the assignment to Ref1 at step(d)) and so creating a dangling pointer and potential serious problems at (e)). The Ada rule that the lifetime of the access type (rather than that of the access variable) must be no longer than that of referenced object was chosen for implementation simplicity. It means that the check can be performed statically at compile time whereas dynamic checks at
A Barnes, 2004
4
CS2130/Unit 8
run-time would be necessary if the rule referred to the lifetime of the access variable. Steps (c) and (d) and all similar 'pointer' assignments would need to be checked at run-time. The Ada rule makes some code that is actually safe illegal. For example
PROCEDURE Main IS TYPE Int_Ptr IS ACCESS ALL Integer; BEGIN DECLARE I : ALIASED Integer; Ref2 : Int_Ptr; BEGIN Ref2 := I'ACCESS; -- (f) !? illegal ....... -- safe to dereference here Ref2 ....... -- as I has same lifetime as Ref2 END; ........ END Main;
If the programmer is absolutely convinced the program is safe, the compiler checks can be subverted by using the UNCHECKED_ACCESS attribute at (f)
Ref2 := I'UNCHECKED_ACCESS; -- (f) legal but potentially unsafe
Generally the use of this attribute should be a last resort as it subverts Ada's strong type checking (we could equally well apply the attribute to a variable of any type in step (f). The necessity for using UNCHECKED_ACCESS can often be avoided by a (usually minor) restructuring of the code or by the use of access parameters (see below). Note that if UNCHECKED_ACCESS had been used in the first and second examples above the assignments at (a) and (c) would have been legal, but later disaster could ensue because of the dereferencing of dangling pointers at steps (b) or (e). As we have seen in unit 7 a second way of creating dangling pointers is to deallocate dynamically allocated storage. In Java there are no pointers as such and so such problems are avoided; it is not possible to set up references to values of primitive types (such as int and float) in Java. Reference semantics are used for all objects (including arrays), but since such objects can only be created by an allocator and storage deallocation is done automatically by the garbage collector it is not possible to create dangling references to deallocated objects in Java. Access Parameters in Ada The Ada accessibility rules are rather severe and (as we have seen) some programs, though safe, are illegal. Consider also the following
PROCEDURE Main IS TYPE T IS ...; -- any old type
PROCEDURE P IS TYPE T_Ptr IS ACCESS ALL T; Ptr : T_Ptr := X'ACCESS; -- (g) illegal BEGIN ....... -- manipulate X indirectly via Ptr END P; PROCEDURE Q IS X : ALIASED T; BEGIN P; END; BEGIN Q; END Main; -- call Q
-- call P
A Barnes, 2004
5
CS2130/Unit 8
The declaration at (g) is actually illegal as X is out of scope (since Ada uses static rather than dynamic scoping), but if we could have assigned the 'address' of X to Ptr nothing could have gone wrong because the dynamic lifetime of type T_Ptr is shorter than the lifetime of X. One solution would have been to move the declaration of X to top-level in Main before the declaration of procedure P; however the use of a non-local variable is rather unstructured. To cater for such a common situation in a structured manner, Ada provides a new form of parameter known as an access parameter.
PROCEDURE Main IS TYPE T IS ...; -- any old type
PROCEDURE P(Ptr : ACCESS T) IS BEGIN ....... -- manipulate X indirectly via Ptr END P; PROCEDURE Q IS X : ALIASED T; BEGIN P(X'ACCESS); END; BEGIN Q; END Main; -- call Q
-- call P with 'access to X' as its AP
The parameter Ptr is of an anonymous access type and so we cannot declare other objects of the type. Equality and assignment are thus not meaningful for this type and so, in particular, we cannot assign to Ptr. Also the actual parameter corresponding to an access parameter is not allowed be NULL (this is checked at run-time). Consequently the coding of subprograms with access parameters is often simpler than that of subprograms with parameters of a named access type as there is never any need test if the parameter is NULL. Note that access parameters can often be used as an alternative to IN OUT parameters as they provide read and write access to the data to which they refer.
TYPE T IS ....; X : T; -- any old type
TYPE T_Ptr IS ACCESS ALL T; Ref : T_Ptr := NEW T'(some value of type T); PROCEDURE PIO(IO : IN OUT T) IS Y : T := IO; BEGIN .... IO := some value of type T; ..... END PIO; PROCEDURE PA(Ptr : ACCESS T) IS Y : T := Ptr.ALL; BEGIN ....... Ptr.All := some value of type T; ........ END PA; ......... PIO(X); PIO(Ref.ALL); ....... PA(X'ACCESS); PA(Ref); -- valid calls to PIO -- valid calls to PA
A Barnes, 2004
6
CS2130/Unit 8
Note functions can have access parameters (as they are technically a form of IN parameter) and so data passed via such parameters can be modified by the function2. As we shall see in later lectures access parameters are also much used in object-oriented programming in Ada. Subprogram Parameters It is sometimes useful to be able to pass one subprogram to another subprogram as a parameter. Functions which accept other functions as parameters, are called second-order functions. In functional programming languages second-order functions can usually be defined directly, but in Ada and most other imperative languages subprograms are not first class values and cannot be passed directly to other subprograms. However in Ada (and C and C++, but not Java) we can achieve the same effect by using access to subprogram types; such an access to subprogram value can be created by applying the ACCESS attribute to a subprogram name and the subprogram can be called indirectly by dereferencing such an access value. For example we can write
TYPE ElemFn IS ACCESS FUNCTION(X : Float) RETURN Float; F : ElemFn; Y, Z : Float;
Then F can be made to 'point to' functions of the type Float > Float such as Sin, Cos, Tan etc. 'imported' from the package Ada.Numerics.Elementary_Functions and then the function called indirectly as follows:
WITH Ada.Numerics.Elementary_Functions; USE Ada.Numerics.Elementary_Functions; .......... F := Sin'ACCESS; Z := F(Y); -- call Sin indirectly
is really an abbreviation for F.ALL(Y) , but as with other access types the explicit dereferencing with .ALL is not necessary unless the subprogram has no parameters.
F(Y)
Given a linked list of real values defined by the usual scheme:
TYPE Node; TYPE List IS ACCESS Node; TYPE Node IS RECORD Value : Float; Link : List; END RECORD; ArgList : List;
we could define a second order procedure to apply any function of type ElemFn to each element of the list:
PROCEDURE Map(Fun : IN ElemFn; L : IN List) IS Next : List := L; BEGIN WHILE Next /= NULL LOOP Next.Value := Fun(Next.Value); ...