3.1 ADT overview

Given the restrictions of the built-in struct of C, let us investigate the interface of a record if implementation and efficiency are not major factors.

A record should have a name. The name of a record (type) unique identifies the record type from other record types. Note that C structs can be named.

We should be able to create instances of a record type. A record type is like a cookie cutter, while individual records are like cookies cut out from a cookie cutter. In C, you can create struct objects either from local/global variable definitions, or allocated dynamically using the malloc family of library functions.

Given a record instance (cookie), there should be an operation to access the value of a data member.

There should be a way to dispose of a record (not the record type). This is accomplished in C using the free library function (for objects that are dynamically allocated by malloc). Local variables are automatically cleaned up, while global variables live all the way to the end of the execution of a program.

We should be able to add new members to a record type at run time. Experienced C/C++ systems programmer may find this features pointless. However, database programmers have to tackle the issue of run-time data member creation all the time. This is because the number of columns of a table (in a database) may change (usually extended) after a program is written. At any rate, a data member should consist of a name that uniquely identifies the data member from all other data members. Some also suggest that a data member have a specific type and a default value.

If we can add new members, we should be able to remove existing members from a record type.