Most objects cease to exist when they go out of scope. This may be when the function in which they were created terminates. It may be when the container in which they reside is deleted. At any rate, they can be expected to disappear when the program exits. Persistent objects are those which survive between successive invocations of the program. A classic example of such an object is a database record.

Objects can be stored in a database in one of two ways:

• As conventional records in a standard database system
• As objects

If they are stored in a conventional database, then they are not ready-for-use. They must be read in from a file and constructed manually. If stored as objects in an O-O database (such as POET), they are ready to use immediately after retrieval. To get around this problem, programmers are required to implement their own persistent object systems.

Simple Persistence

In the case of a homogenous collection of objects, this could be dealt with simply. Suppose we have a class to define an employee as follows:

class employee
{
 char *id;   // Employee ID
 char *name;  // Employee name
 float rate;  // Hourly rate

public:
 //Constructors, access methods, etc.
};

employee fred;

There is no way at run time for the programmer to determine that fred is an object of class employee. They must be aware of the fact whenever they write code which will deal with it.

Simple persistence can be achieved by the implementation of the following functions:

class employee
{
  ...
public:
 friend void write employee (ostream &os, const employee &emp );
 friend employee *read_employee (istream &is );
}
void write_employee ( ostream &os, const employee &emp )
{
 os << strlen(emp.id)  << emp.id << ' ';
 os << strlen (emp.name) << emp.name << ' ';
 os << emp.rate << endl;
}

employee *read_employee (istream &is )
{
 employee *newEmp = new employee;
 int slen;

 is >> slen;
 newEmp->id = new char[slen+1];
 is >> newEmp->id;

 is >> slen;
 newEmp->name = new char [slen+1];
 is >> newEmp->name;
 is >> newEmp->rate;

 return newEmp;
}

These functions can then be used to write an employee record to a file, and then read it back in at a later time. Objects of class employee can now be made persistent.

General Persistence

Object Identity refers to the ability of an object to identify itself. This identity is not for the individual object, but defines the class of the object. It is crucial to the implementation of any persistence mechanism which will deal with more than one class of object.

In a general purpose approach, each object must be able to identify its class so that appropriate steps can be taken. At present this requires each object to contain a data member which defines its class. Typically this is a static data member to ensure that only one copy exists per class:

class pers_object
{
public:
 static char *ObjectType;
 ...
}

The general purpose object loader/storer would then inspect this ObjectType member to determine how to save the data or create a new object. The ObjectType string is stored in the file immediately prior to the actual contents of the object. This allows a single file to contain an heterogeneous mix of objects of different classes.

The drawback to this approach is that the load function must be aware of every possible object type which it may be required to load. This may be achieved via a lookup table matching values of ObjectType to the address of a function to call to instantiate the object from file, but there must still be an entry for each possible type. And of course the range of values of ObjectType must be managed to ensure all classes have unique values.

Although it is such a vital component of OOP, the lack of direct support of persistence by C++ means that we are regularly forced to breach the basic concepts of encapsulation and polymorphism to achieve it.