1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records Design Issues: 1. What is the form of references? 2. What unit operations are defined?

2 Record References Definition Syntax –COBOL level numbers for nested records –Other PLs recursive definition Field References –COBOL field_name OF record_name_1 OF... OF record_name_n –Other PLs use dot notation record_name_1. record_name_ record_name_n. field_name –Fully qualified references include all record names –Elliptical references allow leaving out record names if the reference is unambiguous –Pascal's with clause allows to abbreviate references

3 Record Compile-Time Descriptor A compile-time descriptor for a record Record Address Name Type Offset … Name Type Offset field 1 field n

4 Operations on Records 1.Assignment –Pascal, Ada, C allowed it if the types are identical –Ada RHS can be an aggregate constant 2.Initialization –Allowed in Ada Allowed using an aggregate constant 3.Comparison –Ada = and /= ; one operand can be an aggregate constant 4.Move Corresponding –COBOL Moves all fields in the source record to fields with the same names in the destination record Note: the fields may not be in the same order

5 Arrays vs. Records 1.Access to array elements is slower than access to record fields –Array subscripts are dynamic –Field names are static 2.Dynamic subscripts for record fields? –but type checking would be complex –it would be much slower

6 Unions Union –Elements can store different type values during execution Discriminated union –tags for indicating types for type checking Free union –no type checking Design Issues for unions –What kind of type checking should be done? –Should unions be integrated with records? FORTRAN – EQUIVALENCE, No type checking Pascal –both discriminated and nondiscriminated unions

7 Unions Common fields Different fields A discriminated union of three shape variables discriminant field form determines which fields have data values

8 Type Checking of Unions Pascal’s can’t be type checked effectively: –User can create inconsistent unions because the tag can be individually assigned var blurb : record case tag: boolean; true: (i: integer;) false: (x: real;) end; blurb.tag := true; {it's i, an integer} blurb.i := 47; {ok } blurb.tag := false; {it's now x, a real!} write (blurb.x); {writes 47 as real?!} –The tag is optional!

9 Union Examples, cont. Ada –discriminated unions No inconsistent unions, safer than Pascal –Tag must be present –Tag cannot be assigned by itself –All assignments to the union must be aggregate values that include the tag C and C++ –free unions (no tags) Not part of their records No type checking of reference Java has neither records nor unions Evaluation –potentially unsafe in most languages (not Ada)

10 Sets Unordered collection of distinct values from some ordinal type Operations –Union –Intersection –Difference Design Issue –Maximum number of elements in the set base type

11 Pointers and References Provide access to dynamic storage Pointers –The address of the data – a number –Flexible – you can do arithmetic on the addresses! –Few, if any safety checks on access using pointers –E.g. C, C++ References –Points to the data implicitly –No address arithmetic –Much safer –E.g. Java, Lisp

12 Heap Storage Implicit – Automatic Explicit – programmer’s instructions Heap 0 Text Data Stack

13 Problems with Pointers 1.Dangling pointers (dangerous) –A pointer to a heap-dynamic variable that has been de-allocated –To create a dangling pointer 1.Allocate a heap-dynamic variable with one pointer 2.Set a second pointer to the value of the first pointer 3.De-allocate the variable using the first pointer 4.Second pointer is now dangling 2.Lost Variables / MemoryLeaks (wasteful) –A heap-dynamic variable that is no longer referenced –To create a lost variable: 1.Allocate a heap-dynamic variable with a pointer 2.Set the pointer to another heap-dynamic variable

14 Pascal and Ada Pointers Pascal: only for dynamic storage management –Explicit dereferencing necessary - postfix ^ –Dangling pointers are possible - explicit dispose –Memory leaks are possible Ada –A little better than Pascal –Some dangling pointers are avoided Dynamic data is automatically de-allocated at the end of pointer's type scope –All pointers are initialized to null –Memory leaks possible Rare, as explicit deallocation is rarely done

15 C and C++ Pointers C and C++ –Explicit dereferencing and address-of operator –Domain type need not be fixed - void * – void * can point to any type and can be type checked (cannot be de-referenced) –Address arithmetic in restricted forms, e.g.: float stuff[100]; float *p; p = stuff; *(p+5) is equivalent to stuff[5] and p[5] *(p+i) is equivalent to stuff[i] and p[i]

16 Pointer Assignment The assignment operation j = *ptr

17 FORTRAN Pointers FORTRAN 90 –Can point to heap and non-heap variables –Implicit dereferencing –Pointers only to variables with TARGET attribute – TARGET attribute in declaration INTEGER, TARGET :: node –A special assignment operator for non-dereferenced references REAL, POINTER :: ptr ( POINTER is an attribute) ptr => target where target is pointer or non-pointer with TARGET attribute This sets ptr to have the same value as target

18 C++ and Java Pointer/References C++ –Reference Types Constant pointers that are implicitly dereferenced Used for parameters –Advantages of both pass-by-reference and pass-by-value Java –Only references, no pointers –No pointer arithmetic –Can point only to objects (all on the heap) –No explicit deallocator Garbage collection is used No dangling references –Dereferencing is always implicit No memory leaks

19 Dangling Pointers Solutions to dangling pointer problem 1.Tombstone –Extra heap cell that is points to the heap-dynamic variable –The actual pointer variable points only at tombstones –Deallocating heap-dynamic variable sets tombstone to nil –Another pointer can't use it anymore 2.Locks and keys –Pointer is represented as (key, address) pair –Heap-dynamic variable has extra lock cell –Allocating heap-dynamic variable places lock value in lock cell –Pointers have a copy of the lock value in the key cell –Deallocating the variable sets its lock cell to an illegal value –Access via other pointers then causes an error

20 Implementing Dynamic Variables

21 Heap Management Single-size cells vs. variable-size cells Reference counters vs. garbage collection (lazy approach) Reference counter –Every heap-dynamic variable has a counter of pointers currently pointing to it –Once counter becomes 0 memory can be reclaimed –Eager approach –Disadvantages Space required Execution time required Complications for cells connected circularly

22 Garbage Collection Garbage collection –Allocate and disconnect –When all available cells are allocated, gather all garbage –Every heap cell has an extra garbage collection bit All cells initially set to garbage All reachable cells marked as not garbage All garbage cells returned to list of available cells –Disadvantage When you need it most, it works worst Takes most time just when program needs cells in heap most –More efficient methods don’t wait until absolutely necessary

23 Evaluation of Pointers Pointers or references are necessary for dynamic data structures –No modern PL can't be without them Pointers are like goto 's –They widen the range of memory cells that a variable can access Dangling pointers are a problem Memory leaks are a problems Heap management is a problem