Algorithms and Data Structures

More documents

Recommendations

Info

N.Wirth. Algorithms and Data Structures. Oberon version 132 T Ted T Fred T Mary T Adam F F T Eva F F F F Fig. 4.3. Data structure linked by pointers It must be emphasized that the use of pointers to implement recursive structures is merely a technique. The programmer need not be aware of their existence. Storage may be allocated automatically the first time a new component is referenced. However, if the technique of using references or pointers is made explicit, more general data structures can be constructed than those definable by purely recursive data definiton. In particular, it is then possible to define potentially infinite or circular (graph) structures and to dictate that certain structures are shared. It has therefore become common in advanced programming languages to make possible the explicit manipulation of references to data in addition to the data themeselves. This implies that a clear notational distinction must exist between data and references to data and that consequently data types must be introduced whose values are pointers (references) to other data. The notation we use for this purpose is the following: TYPE T = POINTER TO T0 This type declaration expresses that values of type T are pointers to data of type T0. It is fundamentally important that the type of elements pointed to is evident from the declaration of T. We say that T is bound to T0. This binding distinguishes pointers in higher-level languages from addresses in assembly codes, and it is a most important facility to increase security in programming through redundancy of the underlying notation. p: POINTER TO T p^: T Fig. 4.4. Dynamic allocation of variable p^. Values of pointer types are generated whenever a data item is dynamically allocated. We will adhere to the convention that such an occasion be explicitly mentioned at all times. This is in contrast to the situation in which the first time that an item is mentioned it is automatically allocated. For this purpose, we introduce a procedure NEW. Given a pointer variable p of type T, the statement NEW(p) effectively allocates a variable of type T0 and assigns the pointer referencing this new variable to p (see Fig. 4.4). The pointer value itself can now be referred to as p (i.e., as the value of the pointer variable p). In contrast, the variable which is referenced by p is denoted by p^. The referenced structures are typically records. If the referenced record has, for example, a field x, then it is denoted by p^.x. Because it is clear that not the
N.Wirth. Algorithms and Data Structures. Oberon version 133 pointer p has any fields, but only the referenced record p^, we allow the abbreviated notation p.x in place of p^.x. It was mentioned above that a variant component is essential in every recursive type to ensure finite instances. The example of the family predigree is of a pattern that exhibits a most frequently occurring constellation, namely, the case in which one of the two cases features no further components. This is expressed by the following declaration schema: TYPE T = RECORD IF nonterminal: BOOLEAN THEN S(T) END END S(T) denotes a sequence of field definitions which includes one or more fields of type T, thereby ensuring recursivity. All structures of a type patterned after this schema exhibit a tree (or list) structure similar to that shown in Fig. 4.3. Its peculiar property is that it contains pointers to data components with a tag field only, i.e., without further relevant information. The implementation technique using pointers suggests an easy way of saving storage space by letting the tag information be included in the pointer value itself. The common solution is to extend the range of values of all pointer types by a single value that is pointing to no element at all. We denote this value by the special symbol NIL, and we postulate that the value NIL can be assumed by all pointer typed variables. This extension of the range of pointer values explains why finite structures may be generated without the explicit presence of variants (conditions) in their (recursive) declaration. The new formulations of the explicitly recursive data types declared above are reformulated using pointers as shown below. Note that the field known has vanished, since ~p.known is now expressed as p = NIL. The renaming of the type ped to Person reflects the difference in the viewpoint brought about by the introduction of explicit pointer values. Instead of first considering the given structure in its entirety and then investigating its substructure and its components, attention is focused on the components in the first place, and their interrelationship (represented by pointers) is not evident from any fixed declaration. TYPE term = POINTER TO TermDescriptor; TYPE exp = POINTER TO ExpDescriptor; TYPE ExpDescriptor = RECORD op: INTEGER; opd1, opd2: term END; TYPE TermDescriptor = RECORD id: ARRAY 32 OF CHAR END TYPE Person = POINTER TO RECORD name: ARRAY 32 OF CHAR; father, mother: Person END Note. The type Person points to records of an anonymous type (PersonDescriptor). The data structure representing the pedigree shown in Figs. 4.2 and 4.3 is again shown in Fig. 4.5 in which pointers to unknown persons are denoted by NIL. The resulting improvement in storage economy is obvious. Again referring to Fig. 4.5, assume that Fred and Mary are siblings, i.e., have the same father and mother. This situation is easily expressed by replacing the two NIL values in the respective fields of the two records. An implementation that hides the concept of pointers or uses a different technique of storage handling would force the programmer to represent the ancestor records of Adam and Evatwice. Although in accessing their data for inspection it does not matter whether the two fathers (and the two mothers) are duplicated or represented by a single record, the difference is essential when selective updating is permitted. Treating pointers as explicit data items instead of as hidden implementation aids allows the programmer to express clearly where storage sharing is intended and where it is not.
Page 1 and 2:
Algorithms and Data Structures © N
Page 3 and 4:
N.Wirth. Algorithms and Data Struct
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82: N.Wirth. Algorithms and Data Struct
Page 131: N.Wirth. Algorithms and Data Struct
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Page 189 and 190:
Page 191 and 192:
Page 193 and 194:
Page 195 and 196:
Page 197 and 198:
Page 199 and 200:
Page 201 and 202:
Page 203 and 204:
Page 205 and 206:
Page 207 and 208:
Page 209 and 210:
Page 211:
show all

Algorithms and Data Structures

Create successful ePaper yourself

Delete template?

Save as template?