The Heap and One-way Linked Lists

Abstract

In the diagram package the user can create a diagram made up of a series of shapes, each of which contains a number of items. Each shape can consist of any number of items, and there can be any number of shapes. Thus, when the program is written, it is not known how many items are required, or how many shapes are needed. This can be determined only when the program is being run. However, space is needed in which these items and shapes are stored. It would be possible to predeclare this using VAR statements of the form:

$$\matrix{ {{\rm{VAR}}\,{\rm{Shapes}}\,{\rm{:}}\,{\rm{ARRAY}}\,{\rm{[0}}..{\rm{SapeMax]}}\,{\rm{OF}}\,{\rm{Itemes;}}} \cr {\,\,\,\,\,\,\,\,\,\,\,\,\,\,\,\,\,{\rm{Items}}\,{\rm{:}}\,{\rm{ARRAY}}\,{\rm{[0}}..{\rm{ItemMax]}}\,{\rm{OF}}\,{\rm{GCommand;}}} \cr }$$

where ShapeMax and ItemMax are suitable constants, and GCommand is a record defining an item (see chapter 9). This is limiting, as the user is restricted as to the number of GCommands that can make up a shape, and the number of shapes. It is also wasteful of memory, as some shapes may require very few GCommands. A much better solution is one where the memory for a new GCommand is acquired as and when it is needed, that is, when the program is run. This is achieved using the heap (see Wirth[1]).