2.5 Memory Allocation

When an object is allocated off the heap, ownership can be a problem. Who is responsible for deleting it?

NOTE: DBTools.h++ frees you from allocating objects off the heap.

The DBTools.h++ Interface/Implementation strategy makes dealing with the heap unnecessary. The DBTools.h++ interface classes 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 DBTools.h++ classes off the heap, or to operate on pointers to DBTools.h++ 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 DBTools.h++ classes. In fact, the entire DBTools.h++ API is remarkably pointer-free.