1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are...

23
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?

Transcript of 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are...

Page 1: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

1Records

• 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?

Page 2: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

2Record 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_2. ... .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

Page 3: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

3

Record Compile-Time Descriptor

A compile-time descriptor for a record

Record

Address

Name

Type

Offset

Name

Type

Offset

field 1

field n

Page 4: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

4Operations on Records1. 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

1. Moves all fields in the source record to fields with the same names in the destination record

2. Note: the fields may not be in the same order

Page 5: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

5Arrays 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

Page 6: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

6Unions

• 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

Page 7: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

7Unions

Common fields Different fields

A discriminated union of three shape variablesdiscriminant field form determines which fields have data values

Page 8: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

8Type 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!

Page 9: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

9Union 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)

Page 10: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

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

Page 11: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

11Pointers 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

Page 12: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

12Heap Storage

Implicit –

Automatic

Explicit –

programmer’s

instructions

Heap

0Text

Data

Stack

Page 13: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

13Problems 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

Page 14: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

14Pascal 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

Page 15: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

15C 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]

Page 16: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

16Pointer Assignment

The assignment operation j = *ptr

Page 17: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

17FORTRAN 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

Page 18: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

18C++ 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

Page 19: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

19Dangling 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

Page 20: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

20Implementing Dynamic Variables

Page 21: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

21Heap 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

Page 22: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

22Garbage 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

Page 23: 1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.

23Evaluation 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