. . . . . . . . . ( end of section Topics) <<Contents | Index>>
Note that absolute accuracy require fixed point (integer) data. Always represent money
as long integers rather than floating point.
Shouldn't we avoid coercions because they loose data?
First: narrowing coercions do not loose data and so are safe to use.
Second: sometimes the program is required by the clients to through data away.
However.... unexpected coercion does reduced the reliability of programs.
Are all user defined types non-scalar?
No. User defined enumerations and sub-ranges are scalar. However most user-defined types are
records and these are not scalar data types.
Garbage collection -- how and what?
It took 20 years for use to get good ways of collecting garbage. The key problem
is finding out which bits of memory are without pointers and so inaccessible.
An early method was to delay collecting the garbage until memory was nearly full and then following every pointer and marking the data to which it pointed. Then it recycled all the unmarked bits of memory.
A later technique was to add a reference counter to each record. This increased by one when a new pointer was attached and decreased by one when a pointer is removed. Records with zero reference are obviously garbage. This fails to handle circular references.
Modern (post 1990 methods) are called on-the-fly garbage collection and much more efficient
What does delete do?
If we have a
double *p = new double;then we can recycle the space of one double with
delete p;However we must be sure that no other pointers refer to that double space.
delete  p;if p is pointing at an array of items. This is a common error.
To a large extent variant records are limited to Pascal and Ada and
have been made obsolete by Object-Oriented polymorphism (later)
Does type equivalence relate to inheritance?
Not really. Inheritance introduce a different relations between data types.
What is a built-in procedure?
An procedure that is available as part of the compiler. In Pascal: read and write.
Later languages tend to use libraries to supply extra procedures.
Can we run out of memory before a program starts?
It is vital for a compiler to account for every byte of memory used. It must
keep track of how much is left, and where the spare memory is.
This was common when memory was small and not virtual memory. If the compiled program plus the static data filled memory the program often could not start. I spent a couple of months fighting this problem in my PhD back in 1968-70.
This was very common with COBOL and FORTRAN because each function and
subprogram has a single static activation record ... even if it was never called. The Algol-based
languages allocate activation records dynamically when needed, and remove them
when done. As a result programs needed less memory and ran slower.
Why are the program at the top of figure 5.4 and the static memory at the bottom.
(1) the lower addresses are at the top and code is inserted into memory with smaller
addresses before larger ones.
(2) It is simpler to put static variables in a different place -- the top of memory (bottom of 5.4). If we intermix code and data then we need more data to track what is going on.
(3)In many machines we want to put executable code in special memory
segments that can be executed but not overwritten, BUT data needs to change
and must not be executed. Hence we separate data from program.
Why are FORTRAN solutions Algorithm Oriented?
I am suspicious of the term "algorithm oriented".
The only thing that FORTRAN I thru 77 was good at was expressing numerical calculations. Numerical calculations are special kinds of algorithms. Hence expressing complex data structures, objects and so on is almost impossible in the early FORTRANs. The latest versions claim to solve this problem.
. . . . . . . . . ( end of section Questions) <<Contents | Index>>
An example of a Pascal type data structure:
[ lab09.html ]
-- a simple symbol table. The code has been completed,
but I've deleted the remove procedure. In the lab
you must reconstruct it.
[ 10.html ]
. . . . . . . . . ( end of section CS620 Session 9 Imperative languages and Pascal) <<Contents | Index>>