Download Chapter 5

Chapter 5
Abstraction I:
Encapsulation
 In the construction of large programs, we
need to design and implement new data
types.
• Designing the specification of the abstract
data type (attributes and operations).
• Implementing it.
Like a section in a university registration system.
2
 Basic mechanisms providing the
programmer ability of creating new data
types and operations on that type:
• Subprograms
– correct use of the new type is the programmer
responsibility.
• Type declarations
– the programming language partly support the
correct use of the new type.
• Inheritance
3
5.1. Abstract Data Types
 Early languages (FORTRAN,COBOL)
• subprogram definition
 Ada and C++
• package and class
 data type
• a set of data objects
• valid operations on them (early 1970s)
4
Data Abstraction
 A set of data objects, ordinarily using one
or more type definitions,
 A set of abstract operations on those data
objects, and
 Encapsulation of the whole in such a way
that the user of the new type cannot
manipulate data objects of the type except
by the operations defined.
5
Information Hiding
 Each program component should hide as
much information as possible from the
users of the component.
Program design
6
Encapsulation
 The user of the abstraction
• Does not need to know the hidden information
in order to use the abstraction, and
• Is not permitted to directly use or manipulate
the hidden information even if desiring to do
so.
Language design
7
5.2. Encapsulation By
Subprograms
 An abstract operation defined by the
programmer.
 A subprogram definition:
• specification
• implementation
8
Specification of a Subprogram
 The name of the subprogram.
 The signature (prototype) of the
subprogram (number, order and data type
of arguments and results).
 The action performed by the subprogram,
(a description of the function it computes).
9
 In C :
• void Sub(float X, int Y, float *Z, int *W);
 In Ada :
• procedure Sub(X: in REAL; Y: in integer; Z: in out
REAL; W: out BOOLEAN)
• Sub : real1* integer * real2 --> real3 * Boolean
10
Implementation of a Subprogram
 Subprogram body:
• local data declarations
• statements
float FN(float X, int Y)
{float M(10); int N;
…
}
signature
dcl
statements
 subprograms are like primitive operations,
but the programmer must explicitly declare11
Subprogram Definition and
Invocation
 Definitions and activations
• Programmer writes a subprogram definition
as a static property of a program.
The definition serves as a template for creating
activations during execution.
• During execution, if the subprogram is called
(or invoked), an activation of it is created.
12
 Subprogram definition is like a type
definition
 and subprogram activation is like a data
object of that type.
13
Subprogram Activation
 Is a type of data object,
 as a block of storage that contains certain
component data items,
 storage allocated when it is created, freed
when it is destroyed,
 has a lifetime (between call and return),
 it is executed, reference and modify other
data objects during execution. (these are the 14
differences with other data objects)
Implementation of Subprogram
Definition and invocation
Float FN(float X, int Y)
{const initval=2;
#define finalval 10
float M(10);int N;
…
N = initval;
if (n<finalval){…}
return (20*X+M(N));}
15
Components needed for an
activation of the subprogram
 FN’s signature: storage for parameters and
result
 DCLs: storage for local variables
 storage for literals and defined constants
 statements: storage for executable code
fig. 5.1. Page 205
16
Structure of a subprogram
activation
 Split the template into two parts:
• A static part, code segment.
– Constants and executable code.
– Invariant during execution.
– Shared by all activations.
• A dynamic part, activation record.
– Parameters,function results, local data ,
housekeeping data (temporary storage areas,
return points, linkages for referencing non-local
variables).
– A copy for each activation.
(fig. 5.2. P.206)
17
Storage Management
 Access to the components: using the base-
address-plus-offset calculation.
 Allocation of
a block of appropriate size on
a subprogram call, freeing the block on
return.
18
Generic Subprograms
 A generic subprogram name is overloaded .
 p.207, p.208
19
Type Definitions
 Type definition: definition of a class of data
objects.
• A type name
• declaration of the structure of a class of data
objects.
p. 209,210
20
Advantages of type definitions
 Simplifying program structure,
 Simplifying the program modification,
 as an argument to a subprogram.
A kind of encapsulation and information
hiding.
21
implementation
 A type definition is used only during
translation.
• Enters the information from a type definition
into a table during translation,
• using it during execution.
(storage representation: storage management,
type checking)
22
Type Equivalence
 What does it mean to say that two types are
“the same”?
(a data type issue)
 What does it mean to say that two data
objects of the same type are “equal”?
(a semantic issue, r-value of a data object)
23
Type Equality
Program main(input, output);
type Vect1: array[1..10] of real;
Vect2: array[1..10] of real;
var X,Z: Vect1; Y:Vect2;
procedure Sub(A: Vect1);
…
end;
begin
-main program
X:= Y;
Sub(y)
24
Type Equality
 Name equivalence
• only if they have the same name.
• in Ada, C++, subprogram parameters in Pascal
 Structural equivalence
• if they define data objects that have the same
internal components. ( the same storage
representation so the same accessing
formulas and the same run-time
implementation)
25
• older languages (FORTRAN, COBOL, PL/1), C,
Name Equivalence
Disadvantages
 There can be no anonymous types.
• If we have
var W: array[1..10] of real;
W can’t be used as an argument, its type has no
name.
 A single global type definition must be
used. A single type definition must be used
in all or large parts of a program
(transmitting as an argument through a 26
Structural Equivalence
Disadvantages

Several questions arise when two types are
structurally equivalent.
• For records, must the component names be identical?
• Or does it suffice to have the same number and type of
components in the same order?
• If record component names must be identical, then
must the components be in the same order?
• Must array subscript ranges be identical?
• Or is it sufficient to have the same number of
components?
• Must the literals in two enumeration types be the same27
Structural Equivalence
Disadvantages
(cont.)
 Two variables may be structurally
equivalent, even though the programmer
declares them as separate types.
• For example: type Meters = integer;
liters = integer;
var Len: Meters;
Vol: Liters;
many type errors may go undetected.
28
Structural Equivalence
Disadvantages
(cont.)
 Determining whether two complex type
definition are structurally equivalent, if
done frequently, may be a costly part of
translation.
29
Data Object Equality
 Once the compiler determines that two
objects are the same type, are the two
objects equal?
• Stack equality.
• Set equality.
Programmer-defined data, separate operation
for equal
P. 214
30
Type Definitions with Parameters
 Parameterizing the type definition
to be
used repeatedly with different
substitutions for the parameters.
 Parameters like
• class size in Ada
• a type in ML
• no parameterized types in Pascal
31
5.4. Storage Management
 Different features in a language causes
different storage management techniques
to be used.
• FORTRAN: no recursive calls, no dynamic
storage management.
• Pascal: stack-based storage management.
• LISP: garbage collection.
Language implementers decide about the
details.
32
Major Run-Time Elements
Requiring Storage
 Data
 operations
33
Data and program Requiring
Storage
 Code segments for translated user
programs.
 System run-time programs.
• Supporting user programs.
• Like library routines, software interpreters or
translator, storage management routines.
 User-defined data structures and
constants.
 Subprogram return points.
34
 Referencing environments.
• Identifier associations (LISP A-list)
 Temporaries in expression evaluation.
• Recursive function calls make it a lot.
 Temporaries in parameter transmission.
• Resulting values for evaluation of actual
parameters are stored in temporaries until the
total evaluation is completed.
35
 Input-output buffers.
• Temporary storage areas used between the
time of the actual physical transfer of the data
to or from external storage and the programinitiated input / output operation.
 Miscellaneous
system data.
• System data like tables, status information for
input-output, ...
36
Major operations requiring
storage
 Subprogram call and return operations.
• Activation record,
• local referencing environment, …
 Data structure creation and destruction
operations.
• new - dispose in Pascal.
• malloc - free in C
 Component insertion and deletion
operations.
37
Programmer- and SystemControlled Storage Management
 Programmer control of storage
management
• place a large and often undesirable burden on
the programmer,
• may interfere with the necessary systemcontrolled storage management.
 Programmer can cause dangling
references and garbage.
38
 What language?
• Protection for the programmer by using a
language with strong typing and effective
storage management features,
• decrease in performance
OR
• performance
• more risk in having errors and fail during
execution.
39
Storage Management Phases
 Initial allocation
 Recovery
 Compaction and reuse
40
Static Storage Management
 Simplest
 static allocation
 no run-time storage management
 no concern for recovery and reuse
 efficient
 in COBOL and FORTRAN
41
 In FORTRAN
• each subprogram is compiled separately,
• the code segment includes an activation
record
– compiled program,
– its data areas,
– return point location,
– miscellaneous items of system data.
42
Stack-Based Storage
Management
 Simplest run-time storage management
technique.
 Based on the nested last in first out
structure in subprograms calls and
returns.
 Automatic compaction.

In Pascal : a single central stack of activation records,
and a statically allocated area for subprogram code
segments and system programs.
43
Heap Storage Management:
Fixed-Size Elements
 A heap is a block of storage within which
pieces are allocated and freed in some
relatively unstructured manner.
 Need for heap , when a language permits
storage to be allocated and freed at
execution time.
 Fixed size elements allocated => no need
for compaction.
Page 224, fig. 5.7.
44
Recovery
The problem: identification of reusable
element, solutions:
 Explicit return by programmer or system.
• Natural, but cause garbage and dangling
reference. P.226
 Reference counts.
• Cost of maintaining. P.227
• popular with parallel processing systems.
 Garbage collection.
45
Garbage Collection

Dangling references more dangorous
 Two stages
• Mark
– garbage collection bit, set off if it is active.
• Sweep
– links the “on” elements to the free list.
When is a heap element active?
– There is a pointer to it from
– outside the heap
– another active heap element
46
 Three critical assumptions
• any active element must be reachable by a
chain of pointers beginning outside the heap.
• It must be possible to identify every pointer
outside the heap that points to an element
inside the heap.
• It must be possible to identify within any active
heap element the fields that contain pointers
to other heap elements.
47
P. 231
Heap Storage Management:
Variable-Size Elements
 More difficult
 if space for
programmer defined data
structures is sequential, like arrays or
activation records.
 Major difficulty : reuse of recovered space.
48
 Initial allocation and reuse.
 reuse directly
from a free-space list.
• First-fit method
• best-fit method
keeping free-space list in size order.
 Recovery with variable-size blocks.
• In first word of each block: a length indicator.
 Compaction and memory fragmentation
problem.
49
 Compaction approaches:
• Partial compaction
– only adjacent free blocks
• Full compaction
– active blocks may be shifted
50
End of chapter 5
51