C++ Programming - Persistence
by Wrox Books
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.
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:
char *id; // Employee ID
char *name; // Employee name
float rate; // Hourly rate
//Constructors, access methods, etc.
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:
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;
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;
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.
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:
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.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
More Web Development Articles
More By Developer Shed