Memory Allocation
When an object is allocated off the heap, ownership can be a problem. Who is responsible for deleting it?
NOTE: SourcePro DB frees you from allocating objects off the heap.
The Interface/Implementation strategy of the DB Interface Module makes dealing with the heap unnecessary. The interface classes of the DB Interface Module consist only of a pointer to an implementation class instance and an invisible pointer to a virtual function table. The implementation is reference counted, so that when no further interface instances reference the given implementation instance, the implementation instance is automatically deleted. Because copy constructors and assignment operators are very efficient, there is little reason for your applications to allocate Interface Module classes off the heap, or to operate on pointers to Interface Module classes. Of course, you aren’t prevented from doing so, but it is unnecessary.
For example, suppose we require a class, each of whose instances corresponds to a single row of a database table. It might be handy to carry along a reference to the database holding the physical table:
class Part {
public:
Part(const RWDBDatabase& db, int partID);
.
.
.
private:
RWDBDatabase db_;
};
Part::Part(const RWDBDatabase& db, int partID)
: db_(db)
{
// get a row from the "parts" table in db, keyed by partID
}
Notice that we are able to embed an
RWDBDatabase instance in each
Part without incurring undue overhead. Similarly, our
Part constructor is able to initialize the embedded
RWDBDatabase instance by invoking the
RWDBDatabase copy constructor, another low-overhead operation. It is unnecessary to declare a pointer to an
RWDBDatabase anywhere, so it is unnecessary to do any explicit memory management of classes in the DB Interface Module. In fact, most of the API of the DB Interface Module is remarkably pointer-free.
