EDM FAQ: The destructor, destroy, and deallocate methods


The CDF Run II EDM protocol requires that a StorableObject class declare its destructor protected. This insures that all StorableObjects are created in allocated memory (not on the stack) which the EventRecord can control. Since all StorableObjects have virtual methods, the destructor must be declared virtual.

class ToyMuon
{
  protected:

    virtual ~ToyMuon(void) { }  // StorableObject destructor always does nothing
}

Instead of using the C++ destructor mechanism, to deallocate memory for instance, The EDM uses a parallel mechanism with public virtual methods destroy() and deallocate(). destroy() calls dellocate() then deletes itself. deallocate() deallocates memory allocated by this class, then it calls the deallocate() method of its immediate base class. For instance, for ToyMuon which is derived directly from StorableObject, these are declared and then implemented by:

class ToyMuon
{
  public:

    virtual void destroy(void) ;          // Pseudo-destructor
    virtual void deallocate(void) ;       // For child class use
}

void ToyMuon::destroy(void)
{ ToyMuon::deallocate() ;         // Perform resource deallocation
  delete this ;                   // Commit suicide
}

void ToyMuon::deallocate(void)
{ // ToyMuon has nothing to deallocate itself
  StorableObject::deallocate() ;  // But its base class may have something to deallocate
}
Note that the calls to destroy and deallocate are specifically prefaced by the class name of the method. This can be very important, as it insures that the appropriate method is executed where a base class pointer is being used to trigger the calls.


Comments on this page may be sent to Rob Kennedy