DS4: Advanced Data Objects
1
DS 4: Advanced Data Objects
Review
Structured data types (fixed or variable size, hetero or homogeneous, array or
something else (tree, list)
Strings (separate type or array of characters, static or dynamic)
Arrays (indice types, allocation and sizing tim
ing issues, slices)
Records (variant records)
Sets (size limits, binary encoding)
Synopsis
Pointers, Executable Data Objects, Files, Data Encapsulation & Abstraction
References
Pratt &Zelkowitz 5, 6, 7.1
DS4: Advanced Data Objects
2
Pointer Types
A pointer is a data type in which the
values of variables are memory addresses (or the
special value 'nil'). Pointers are mainly used
to provide indirect addressing (to hold a memory location
–
for parameters/arrays)
combined with dynamic allocation/deallocation operators, to provide dynamic
storage management
DS4: Advanced Data Objects
3
Pointer operations:
referencing: setting a pointer to point at a memory location (either the same as
another pointer, or newly allocated memory)
dereferencing: obtaining, not the address given by the pointer, but the contents of
that
address
allocation: specifically setting the pointer to reference newly allocated memory
deallocation: specifically freeing up dynamic memory (and un
-
pointing the pointer)
DS4: Advanced Data Objects
4
Problems:
Misdirection of pointers is easy to create and difficult to debug. S
pecific forms this
takes are:
dangling pointers: the memory location has been deallocated, but a pointer still
references it (some languages provide checks in the compiled code to prevent this).
a = new Person();
a = null;
a.name = “bob”
lost objects: al
located memory to which no pointer any longer points, so the allocated
memory cannot be referenced
-
even to deallocate it.
Garbage collection: deallocation of dynamic memory and the associated pointers
leads to fragmentation of memory. Thus deallocation
schemes require a garbage
management mechanism.
DS4: Advanced Data Objects
5
In addition to the operations given above, C permits pointer arithmetic (+/
-
the size of
the item), allowing arrays to be manipulated with pointers
DS4: Advanced Data Objects
6
Alternatives to Pointers
In most imperative languages, p
ointers are the riskiest, most error prone, parts of the
language. Yet they are normally used to implement only a small range of structures:
lists, trees, rings, stacks.
Some languages provide either as part of their language, or as part of their standard
libraries: standard implementations of these structures.
DS4: Advanced Data Objects
7
Executable Data Objects
In C, Java, Perl, Clean, there is a clear distinction between code and data. However this
is not true of all languages. In lisp, almost everything, including executable code
, is a
list. In most logic programming languages, executable code is built up out of structures
(ie the logic programming analogue of records), and a structure may be passed to a
special predicate (rule) for execution
DS4: Advanced Data Objects
8
Files
The file types supported by a
language usually fall into one of the following classes:
Sequential Files
: Files that may only be accessed record by record.. and only for either
reading or writing. In many languages, each element of the file corresponds to one
data object (which may be
an array or object). Usually the data object may not
contain pointers (which become meaningless).
Text files:
A file of characters, but also usually provided with operations for reading
or writing numbers.
Interactive File Input
-
Output
: Not usually support
ed by languages, problems being in
both read and write mode, buffering, end
-
of file.
Direct Access Files
: Each data object in the file is assigned a key. A particular record
may be read or written by specifying that key.
Indexed Sequential Files
: As above,
but files may also be read sequentially, starting
from the location that was previously accessed.
DS4: Advanced Data Objects
9
Encapsulation
Say a program is being constructed to deal with a database organising the academy. It
would be sensible to first define the major data compon
ents: a student, a staff member,
a course, a list of students, a list of staff members, a list of courses. Then the common
operations could be defined: enter a student, delete a student, assign/remove a staff
member to a course, assign/remove a student to
a course.
Ideally we would like the various data structures to only be handled as parameters
being passed to subprograms. So that once the subprograms are written, it is no longer
necessary to know the structure of the data types. So we would develop a nu
mber of
abstract data types
, for example a student, that may be added to a list, removed from a
list, be added to a course, may be printed, may be assigned a mark for a course.
Once the basic code is written, ideally there should be no obvious difference
between
an abstract data type and one of the provided data types.
So to develop an abstract data type, a language must provide
a way to define
data objects
a way to define
abstract operations
on those objects
DS4: Advanced Data Objects
10
a way to
encapsulate
the data so it may only
be manipulated by abstract operations.
Example of Abstract Data Type
The abstract data type 'stack' is a standard example in textbooks. It is a relatively
widely used data type that is rarely provided as a built
-
in type in imperative or object
-
oriented la
nguages, though it is very close to the list data type provided in most
functional and logic languages.
A stack may be defined via the abstract operations:
create(stack)
creates/initialises a stack
destroy(stack)
deallocates storage for the stac
k
empty(stack)
boolean function:
true if stack empty, else false
push(stack, element)
DS4: Advanced Data Objects
11
pushes the element onto the stack
pop(stack)
removes top element from the stack
top(stack)
returns top element of the stack
The following might tur
n up as code fragments:
stk1, stk2: stack of colour;
colour1, colour2: colour;
.
push(stk1, colour1);
push(stk2, colour2);
if (not empty(stk1))
then temp := top(stk1);
.
DS4: Advanced Data Objects
12
push(stk2,temp);
DS4: Advanced Data Objects
13
You might decide to implement the stack data type using
arrays;
struct current{
int size;
int[] elements;
};
int empty(struct stack current) {return size==0;}
main()
{ struct current myStack; if (empty(myStack)) …}
however, you might find, because of the way this particular program is used, that
memory
management of an array implementation becomes too expensive.
DS4: Advanced Data Objects
14
Because of the data abstraction, it is possible to change the underlying representation to
a linked list, but the rest of the program will not have to be altered.
struct current{
linked
list * head;
};
int empty(struct stack current) {return head==NULL;}
main()
{ struct current myStack; if (empty(myStack)) …}
Some languages allow data abstraction explicitly (i.e. in Java with a class), in some it
can be implemented implicitly (i.e. as w
e are doing with C)
However, in languages with implicit abstract data types, the data type implementor
could not be certain that the data type user did not refer directly to the underlying
representation
-
this would only be picked up when the using progra
m failed to
compile with the new representation.
main(){ struct current myStack; if (myStack.size==0 …}
DS4: Advanced Data Objects
15
Design Issues for Data Abstraction
must provide a syntactic unit to encapsulate the type definitions
must provide subprogram definitions of the abst
raction operators
must be possible to hide the representation
must be possible to make the abstraction operators externally visible
The language should not automatically provide operations for ADTs other than the
bare essentials.
DS4: Advanced Data Objects
16
For assignment, langu
ages either
i) treat it as an operator (so that the implementor can overload it),
ii) provide it by the language,
iii) force a programmer to use conventional code
Person a;
Person b;
a=b; //can = be defined by the programmer
procedure “=” (Person a,
Person b)
{a.name=b.name; a.age=b.age; a.income=b.income;}
DS4: Advanced Data Objects
17
Other issues
Should the encapsulation construct define only one ADT, or permit multiple
definitions in one unit?
Should there be any restriction on the data types that can be abstract? (res
trictions
to pointer types can avoid recompilation of calling units, since the representation of
the pointer does not change, only the representation of what it points to)
Can ADTs be generic (as the stack construct above was), or should we have to
define
separate ADTs for stacks of colour, of integer, of char....?
DS4: Advanced Data Objects
18
Review
Pointers (indirect addressing/memory allocation & deallocation)
Executable Data Objects (functional & logic languages)
Files (text
–
data types, simultaneous IO, indexed, indexed seque
ntial)
Issues for Data Encapsulation Mechanisms (implicit/explicit, information hiding,
only be pointers, generic)
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Comments 0
Log in to post a comment