Run-time type information and incremental loading in C++

"September 1993."Includes bibliographical references (p. 15).Supported by the Productivity From Information Technology (PROFIT) Research Initiative at MIT.Murali Vemulapati, Sriram Duvvuru, Amar Gupta

A dossier driven persistent objects facility

technical reportWe describe the design and implementation of a persistent object storage facility based on a dossier driven approach. Objects are characterized by dossiers which describe both their language defined and "extra-linguistic" properties. These dossiers are generated by a C+-f- preprocessor in concert with an augmented, but completely C++ compatible, class description language. The design places very few burdens on the application programmer and can be used without altering the data member layout of application objects or inheriting from special classes. The storage format is kept simple to allow the use of a variety of data storage backends. Finally, by providing a generic object to byte stream conversion the persistent object facility can also be used in conjunction with an interprocess communication facility to provide object-level communication between processes.

Modules as values in a persistent object store

Journal ArticleWe report on an object manager (OM) providing persistent implementations for C ++ classes. Our OM generalizes this problem to that of managing persistent modules, where the module concept is an abstract data type (ADT). This approach permits a powerful suite of module manipulation operations to be applied uniformly to modules of many provenances, including non-class based entities such as conventional object files, application libraries, and shared system libraries. OMOS, a generalized linker and loader, plays a central role in our OM. Class implementations are represented by OMOS modules, which in turn are constructed from OMOS meta-objects encapsulating linkage blueprints. We cleanly solve the problems of (i) logically (but not physically) including executable object files in our OM, (ii) reconciling class inheritance history and linkage history, and (iii) supporting alternative implementations of a class, for client interoperability or version control