Main Page Class Hierarchy Alphabetical List Compound List File List Compound Members File Members Related Pages

# Dump.h File Reference

`#include "ace/pre.h"`
`#include "ace/Synch.h"`
`#include "ace/Dump_T.h"`
`#include "ace/post.h"`

Include dependency graph for Dump.h:

This graph shows which files directly or indirectly include this file:

## Compounds
class | ACE_Dumpable
| Base class that defines a uniform interface for all object dumping. More...
class | ACE_Dumpable_Ptr
| A smart pointer stored in the in-memory object database ACE_ODB. The pointee (if any) is deleted when reassigned. More...
class | ACE_ODB
| This is the object database (ODB) that keeps track of all live ACE objects. More...
struct | ACE_ODB::Tuple

## Detailed Description

Dump.h,v 4.15 2001/07/31 14:17:24 shuston Exp

A prototype mechanism that allow all ACE objects to be registered with a central in-memory "database" that can dump the state of all live ACE objects (e.g., from within a debugger).

The macros which allow easy registration and removal of objects to be dumped (ACE_REGISTER_OBJECT and ACE_REMOVE_OBJECT) are turned into no-ops by compiling with the ACE_NDEBUG macro defined. This allows usage to be removed in "release mode" builds without changing code.

There are several interesting aspects to this design:

1. It uses the External Polymorphism pattern to avoid having to derive all ACE classes from a common base class that has virtual methods (this is crucial to avoid unnecessary overhead). In addition, there is no additional space added to ACE objects (this is crucial to maintain binary layout compatibility).

2. This mechanism can be conditionally compiled in order to completely disable this feature entirely. Moreover, by using macros there are relatively few changes to ACE code.

3. This mechanism copes with single-inheritance hierarchies of dumpable classes. In such cases we typically want only one dump, corresponding to the most derived instance. Thanks to Christian Millour (chris@etca.fr) for illustrating how to do this. Note, however, that this scheme doesn't generalize to work with multiple-inheritance or virtual base classes.

Future work includes:

1. Using a dynamic object table rather than a static table

2. Adding support to allow particular classes of objects to be selectively dumped.

Author:
  Doug Schmidt