 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to database management systems and more particularly to a system and method providing support for long-term storage and retrieval of objects created by application programs written in object-oriented programming languages.
2. Description of Related Art
Many new computer software applications, such as Computer-Aided Design and Manufacturing, Computer-Aided Software Engineering, multimedia and hypermedia information systems, and Artificial Intelligence Expert systems, have data models that are
much more complex than previous systems, both in content and inter-object relationships. Object-oriented languages provide the application developer the mechanism to create and manipulate the data models inherent in these applications. Database systems
provide long term storage of the data created by these applications. However, existing languages and databases are insufficient to develop these applications because existing object-oriented languages do not provide direct support for long-term storage
and sharing of objects, existing commercial database systems (hierarchical, network, and relational) do not support the necessary complex object-oriented data models, and existing database systems require an application developer to use different
languages and modeling paradigms when building applications.
There have been various research and commercial efforts aimed at developing OODBs. These OODBs vary in type of data model employed, application program interaction, object access method, method of persistent object store, etc. Examples of these
current OODBs, and their weaknesses, will now be considered.
Iris (Hewlett Packard) and GemStone (Servio Corporation) are representative OODBs employing new proprietary object-oriented data models, while Vbase (Ontologic), Orion (Microelectronics and Computer Technology Corporation), and DOME (Dome
Software Corporation) are examples of OODBs incorporating proprietary extensions to existing programming language data models. In these types of OODBs, application developers are required to learn a new proprietary data model in order to effectively use
the OODB. Since their data model is new, using it often results in a loss of productivity as application developers learn the new language. In Orion, instances of user-defined classes cannot be stored in the database unless they have been derived from
Orion-defined classes. In addition, GemStone and Orion do not allow for an instance of their classes to be transient; that is, every object created in a GemStone- or Orion-based application will be stored in the database unless it is specifically
deleted. Another problem with developing a new data model is that it requires application developers to rely on a single source of application development tools, such as language compilers, object libraries, and program debuggers, which limits
widespread acceptance of these OODBs.
POSTGRES (University of Berkeley) is an example of an OODB employing another type of data model, that of a proprietary extension to an existing relational database. POSTGRES is a combination of an extended relational and object-oriented
database. Objects are created using relational table descriptions, while functions to manipulate the objects are created using the POSTQUEL query language as well as conventional languages (C and LISP). In addition, if the application developer wishes
to add indices over user-defined types, they must write and register with POSTGRES functions to perform the various comparison operations between two objects of the same user defined type. Since the latter mode of creating functions requires the
application developers to map between the POSTGRES and C/LISP data models, which can be error prone and distracting from the task of developing the application system, this strategy does nothing to alleviate the burdensome requirement to use different
languages and modeling paradigms when building applications. This problem of mapping between the object-oriented and relational data models was discussed in-depth in the Intermedia OOPSLA '87 conference paper.
Ontos(Ontologic) and Object Store(Object Design) are representative of OODBs employing the last type of data model, namely the use of an existing programming language data model (e.g., using the C++ programming language data model for writing
software programs and interacting with the database). Both systems, however, require the use of a proprietary language compiler to add additional code (Ontos) or translate new and non-standard C++ language constructs (Object Store). As with the first
two types of OODBs, this approach requires application developers to rely on a single source of application development tools, which also limits widespread acceptance of these OODBs.
In addition to problems inherent with the type of data models selected, difficulties occur when an application program interacts with an OODB. In the Iris OODB, application developers define object types and develop functions to manipulate the
objects using the proprietary Iris language. Iris provides an interactive interface where requests can be made to retrieve or manipulate Iris objects. The requests are evaluated by performing relational queries (since the objects are stored in
relational tables) and the result is returned as an Iris expression, not as object values or references. Iris provides an embedded object SQL interface, a C language interface (which is not object-oriented), and allows the application developer to
register foreign functions written in existing (possibly non-object-oriented) programming languages. These approaches require the application developer to map the Iris objects into data structures accessible by the programming language, reintroducing
the problems discussed above.
Similarly, the developers of the GemStone OODB also defined a new language, OPAL, which the application developer uses to define object types and functions to manipulate the objects. GemStone provides an interactive development environment for
developing OPAL objects and functions. GemStone also provides a mechanism for existing programming languages (C and Smalltalk) to interact with GemStone. However, unless the applications developer uses only the OPAL language, two data models and
languages must be used to interact with the database, mapping the OPAL objects into structures accessible by the programming language, and thereby resulting in the problems associated discussed previously.
The Vbase OODB requires two separate languages, TDL to define object types, and COP (an extension to the C programming language) to develop application programs. Although application developers do not need to map objects between the data model
and the programming language, they must still use two languages during the development of their programs, with the attendant problems considered above. A further restriction of this system includes the failure to provide access to the database from
other programming languages.
Although the Orion OODB developers used an existing programming language, Common Lisp, for their data model, they developed several proprietary extensions to the language. As with Vbase, there is no need to map between the data model and
programming language with the Orion OODB. However, this approach requires the use of a proprietary language translator.
The developers of POSTGRES, on the other hand, expect most application developers to write programs that interact with file database primarily using the POSTGRES query language, POSTQUEL. Navigation between objects is possible; however, a query
must be issued to perform the navigation instead of accessing the referenced object directly. Application developers can define and implement their own functions including programming language statements, POSTQUEL query statements, and/or calls to
POSTGRES' internal functions. Thus, application developers may have to deal with two or more data models to build their application systems. Such requirement fails to alleviate the problems considered above.
The Ontos approach provides an interface from the C++ language to the database. However, the amount of interaction between the program and Ontos is much higher than is reasonable or necessary due to the requirement of specialized functions that
must be provided by the application developer (e.g., object construction, translation, storage/retrieval, etc.). This burdens the application developer with more work that could have been performed by the database system. Object Store also provides an
interface from the C++ language to the database. However, the interface is accomplished by redefining the semantics of or adding new C++ language constructs, thereby requiring the use of Object Design's proprietary C++ language translator, which limits
widespread acceptance of their system.
Access to an object in an OODB is performed by manipulating the object using predefined functions, using an explicit query, or by coding explicit references in a programming language.
In the Iris OODB, application developers call functions to retrieve or change values in the object. A program cannot receive a reference to an object which could be passed to other functions. In the GemStone, Vbase, and Orion OODBs, individual
objects can be accessed and passed to functions to retrieve or assign values.
In the POSTGRES database, application developers perform queries to retrieve or change values in the object (actually, relational tuples). POSTGRES allows a foreign function to access an object, but as stated above, it must be mapped from the
relational data model to the data model of the foreign function's programming language.
Although most OODBs allow the application developer to explicitly retrieve an object from the database (Iris and POSTGRES do not), they do not allow the application developer to specify when objects related to the original object should be
retrieved. For example, application developers can access objects in Ontos using one of two modes. In the first mode, an object is explicitly retrieved and referenced objects are implicitly retrieved using an object fault capability. In the other
mode, one or more related objects can be explicitly retrieved, but the application must continually check to see if a referenced object is already in memory, and then explicitly retrieve it if it is not. This requires the application developer to employ
two completely different models of accessing persistent objects in the same program, which can easily cause errors in the program by the inadvertent and natural use of one mode where the other mode should have been used.
The approach taken by Object Store is quite different from the above OODBs with regard to object access. Object Store's model is more like a persistent memory (an extension of virtual memory computer operating system) than an OODB. Object
Design chose to completely reimplement the virtual memory management functions of the C++ programming language and the UNIX (TM) operating system. Whenever a persistent object is created or retrieved from the database, it is installed in a portion of
primary memory controlled by Object Design. Thus, references to the object are, in essence, monitored by Object Design's software. If the object is not currently in primary memory, it will be retrieved from the database and installed in primary memory. This style of memory management requires that any class or class library requiring persistence must be written using this memory management scheme, or perform no dynamic memory management thereby resulting in one version of the library for persistent
usage and one version for transient usage. Although this approach improves the object storage and retrieval performance, it is inherently dependent on the underlying computer operating system and memory architecture, and thus not portable to other
computer systems.
Therefore, these approaches either limit how an application program can access an object, or require additional work in order for the program to access an object.
Most OODBs (except for Iris and DOME) have developed their persistent object storage facility utilizing an existing file management system. They had to develop new implementations of the disk storage structures and management, concurrency
control, transaction management, communication, and storage management subsystems. This approach increases the complexity of the overall database system software.
The Iris and DOME OODBs, on the other hand, use existing commercial Relational Database Management Systems (RDBMS) to store their objects. Although the Iris OODB uses Hewlett Packard's relational database HP-SQL, it does not use the SQL
interface to that database, restricting access to the objects to the available Iris functions, Iris interactive browser, C language interface, and embedded Iris SQL. Although Iris allows the application developer to define how objects are to be stored,
the use of Hewlett Packard's RDBMS imposes a limit on the size of an object. The DOME OODB, which uses Oracle Corporation's Oracle RDBMS, and the POSTGRES system, which has its own relational storage system, decomposes objects into one or more entries
in one or more relational tables. This approach requires a relational join whenever more than one attribute value from an object is retrieved. Relational join operations are computationally expensive.
In the GemStone and Object Store OODBs, the unit of concurrency control is not an object but a secondary memory segment, or page. This approach can improve the performance of secondary memory reads and writes, but results in having the storage
facility read, write, and lock more data than may be necessary. In addition, this restricts the amount of concurrent access to objects since the OODB system, and not the application developer, chooses the unit of concurrency control.
Most of the OODBs allow related objects to be clustered together in the persistent object storage. GemStone and Orion only allow clustering controls to be specified when the entire database is defined. Vbase and Ontos allow runtime
specification of clustering controls to store one persistent object as close as possible to another persistent object. Object Store also allows runtime specification of clustering controls to store statically allocated objects in a specific database and
dynamically allocated objects in a specific database or as dose as possible to another persistent object. This requires the application developer to treat similar objects with different models of clustering, which can cause errors in the program by the
inadvertent use of one mode where the other mode should have been used. These systems indicate that such clustering specifications are purely hints which the system may ignore. These clustering hints may require rebuilding of the database if they are
changed, thereby restricting the ability of the application developers to tune the database's performance by altering the physical grouping of objects. Furthermore, the systems based on relational storage, such as Iris, POSTGRES, and DOME, do not allow
user-defined clustering of objects.
SUMMARY OF THE INVENTION
In view of the above problems associated with the related art, it is an object of the present invention to provide a database management system and method which supports long term storage and retrieval of objects created by application programs,
and which uses existing object-oriented programming languages to thereby enable such system and method to be ported to other computer platforms without requiring any modifications to existing language translators or computer operating systems and thereby
not unduly restrict application developers in their choice of computer platform or language translator.
It is a further object of the present invention to provide a database management system and method providing a standard object-oriented programming interface for its database functionality, thereby eliminating any requirement for mixing of
object-oriented and functional, or other, programming styles to confuse the application developer when coding a program's interface to that of the present invention.
It is yet another object of the present invention to provide a database management system and method for adding persistence to existing language objects orthogonally, thereby allowing application programmers to treat persistent and nonpersistent
objects in nearly the same manner and eliminating the need to use two or more data models when building application systems.
Another object of the present invention is to provide a database management system and method that allows the application developer to specify at object definition time how related objects, whether created dynamically or statically, should be
clustered when stored, to thereby provide a capability to adjust the size of storage objects to enhance the overall system performance.
Still another object of the present invention is to provide a database management system and method that reduces the number of interactions with the database management system that an application developer must code to access objects stored in
the database.
It is a further object of the present invention to provide a database management system and method that allows the application developer to specify at application execution time prior to saving a persistent object whether or not to install in
primary memory the persistent objects referenced from the given persistent object at the same time when the given object is later installed in primary memory, either due to explicit or implicit retrieval, to enhance the overall system performance.
A further object of the present invention is to provide maximization of concurrent usage of the objects in the database by making the unit of locking the individual persistent object instead of a page of persistent objects.
It is still another object of the present invention to store objects in a persistent object storage server utilizing a relational database management system by storing an external representation of the object and external references from the
object without decomposing the objects into multiple relational tuples, to enhance the overall system performance.
Yet another object of the present invention is to provide a database management system and method which uses a uniform object translation methodology thereby eliminating the need for application developers to perform this complex computer-and
language-dependent task.
In accordance with the above objects of the invention, the preferred embodiment of the present invention consists of four software modules to provide database services to application developers. They are referred to as the Data Definition
Language (DDL) translator, the Object Management System (OMS), the Object Translation System (OTS), and the Persistent Object Storage Server (POS Server).
The present invention presents an application interface for programming languages which does not require any extensions to the languages, modifications to existing language translators, or development of proprietary language translators.
Furthermore, the present invention implements an object fault capability which reduces the number of interactions that an application must perform with the database management system and database itself. Access of, and navigation between, objects can be
performed using existing language operations in a transparent manner.
Furthermore, instead of requiring the application developers to use one data model to interact with the database and another data model to manipulate the objects in a programming language, the present invention uses the data model of existing
standard object-oriented languages, such as C++ and CLOS, as the data model for the database. This alleviates problems associated with the art discussed above.
Although the present invention can be implemented in any object-oriented programming language, and should therefore not be limited in any way to any specific language, it has been implemented in both C++ and Common Lisp. In the C++ embodiment,
application developers interact solely with the DDL module, in a batch processing mode, and with the OMS module using standard C++ syntax in their application programs. The DDL module accepts object type descriptions on standard C++ programming language
statements (with a few additional syntactic constructs) and extracts sufficient information from the descriptions to enable the OTS module to translate objects between their primary and secondary memory representations. This process is required because
this type description information is not available in the C++ run-time system. To achieve architecture-independent translation, the DDL translator also accepts information describing a specific computer architecture and software system environment in
which the present invention's applications are to be executed. The POS Server uses a standard SQL interface to a commercial relational database.
In the Common Lisp embodiment, application developers interact solely with the OMS module using standard Common Lisp syntax in their application programs. The DDL module is not implemented since the OTS module can extract the necessary
information from the CLOS descriptions during program execution as that information is already available in the Common Lisp run-time system. This embodiment uses a raw disk-based implementation of the POS Server developed by the co-inventors.
The OMS module presents an application interface to perform standard database operations: initializing and terminating the present invention, beginning and committing or aborting database transactions (saving modified objects or discarding them,
respectively), designating objects as persistent (to be saved to the database), explicitly retrieving objects from the database, designating objects as having been modified, removing objects from memory, defining the default storage group for logical
clustering of objects, etc. The OMS module also supports an automatic and implicit retrieval of objects from the database when an application references a previously saved object that is currently not in primary memory. OMS also provides a facility to
associate user-defined names with persistent objects to simplify retrieval of objects. These associations are also stored in the present invention's database. This name-object management module has a well-defined interface and can be replaced with a
module of the application developer's choice.
As stated above, the present invention allows the application program to retrieve persistent objects from the database and reference the persistent object's data members or functions. The present invention accomplishes this by defining a new
data type or class, the ZG.sub.-- PTR, that functions equivalently to the current language constructs for referencing persistent objects (pointers in C++; symbols and values in Common Lisp). In addition, the present invention allows the application
program to implicitly retrieve a persistent object from the database using an object faulting mechanism. When an application program references a persistent object, if the object is already in primary memory, the application program continues with its
operations. If the object is not in primary memory, OMS automatically retrieves the object from the POS and calls upon the OTS module to translate and install the object in primary memory. Finally, the application program is allowed to proceed, unaware
of this object faulting processing.
The OTS module is responsible for translating objects between their primary and secondary memory representations in a computer architecture-independent manner. When an object is being saved, the OTS module uses the information extracted by the
DDL translator to determine the extent, or boundary, of the object and then translates all of the objects within the boundary to a computer architecture independent representation. When an object is retrieved from the POS, OTS creates the appropriate
primary memory representation, assigns the object's values from the stored representation, and allocates OMS data structures for every reference contained in the object to other persistent objects.
The POS Server module provides a stable storage facility for the objects made persistent by the application program. Objects are stored in the computer's long term, or secondary, memory. The POS Server also provides to the OMS module
concurrency control primitives and atomic transactions (all objects are saved or none are saved). Objects are stored as an untyped array of bytes which only OTS understands.
The present invention stores objects via the POS Server in a computer architecture-independent representation utilizing information about the computer's computational, or primary, memory architecture. Information on the content and structure of
the objects is extracted from the object definitions declared in the supported languages. This allows applications written in any of the supported languages to store objects in the same POS. Currently the POS Server is implemented in a modular and
portable fashion using an existing commercial Relational Database Management System (RDBMS). The POS Server interacts with the RDBMS using an embedded Structured Query Language (SQL) interface.
These and other features and advantages of the invention will be apparent to those skilled in the art from the following detailed description of a preferred embodiment, taken together with the accompanying drawings in which:
BRIEF
DESCRIPTION OF DRAWINGS
FIG. 1 is a block diagram showing the operating context of the present invention operates within a computer;
FIG. 2 is a block diagram of the architecture of a preferred embodiment of the present invention;
FIG. 3 is a flow chart depicting the process flow of the DDL translator during execution according to the present invention;
FIG. 4 is a block diagram representing an example of a demon table used within the OMS module of the present invention;
FIG. 5 is a block diagram representing an example of an object map used within the OMS module of the present invention;
FIG. 6 is a block diagram depicting an example of the relationships between a PTR, an encapsulation, an object, and the type description of that object according to the present invention; and
FIGS. 7a and 7b are block diagrams showing the process of object translation between its primary and secondary memory representations according to the present invention.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
The present invention is applicable in the development of object-oriented application systems which require the management, persistence and sharing of complex and interrelated data. Before considering the present invention in detail, however, it
should be noted that although the C++ implementation will be fully described, the preferred embodiment of the present invention can be implemented in any object-oriented programming language. Currently, a C++ implementation of the present invention runs
on systems such as the Sun Microsystems Incorporated Sun4 or the Digital Equipment Corporation DEC3100 series of computer workstations. Also, a Common LISP implementation of the present invention runs on such systems as the Texas Instruments
Incorporated Explorer series of computer workstations.
FIG. 1 shows a block diagram of the operating context of the present invention within a computer. A user 8, which may be human, another computer, or another application, interacts with the interactive devices 10 to send information to, and
receive information from, user interface management system 12. Interactive devices 10 are also known as communication hardware. User interface management system 12, which is also known as communication software in turn sends the information to, and
receives information from, an application software program 14 (hereinafter referred to as "application 14"). Application 14 interfaces with the computer's operating system software 16 (hereinafter referred to as "OS 16") and the present invention
(hereinafter referred to as "OODB 18"). OODB 18 interfaces with OS 16 to utilize various operating system services. OODB 18 also interfaces with a Relational Database Management System Software 20 (hereinafter referred to as "RDBMS 20") to store and
retrieve objects created by application 14. RDBMS 20 interfaces with operating system 16 to utilize various OS system services and with secondary memory storage devices 24 to physically store or retrieve the objects created by application 14 and managed
by OODB 18. OS 16 also interfaces with additional computer hardware 22 as necessary to provide its system services to application 14, OODB 18, and RDBMS 20.
FIG. 2 shows a block diagram of the architecture of a preferred embodiment of the present invention during execution of application 14. All of the modules in OODB 18 are linked together along with a C++ type description 40 (hereinafter referred
to as "types 40"), produced by running the data definition language translator (hereinafter referred to as "DDL 80"; shown in FIG. 3) on a set of application-defined classes, to form a library that can be linked with application 14 to form a program that
can be executed in the computer environment shown in FIG. 1.
Application 14 interfaces directly with the object management system 42 (hereinafter referred to as "OMS 42") and creates or deletes Persistent Object References 44 (hereinafter referred to as "PTR 44") to create, retrieve, and access persistent
objects managed by OMS 42.
OMS 42 interfaces with name manager 46 to manage an association of names supplied by application 14 with independent persistent objects created or retrieved by application 14 using PTRs 44. OMS 42 interfaces with demon table 48 to execute
functions defined by application 14 and registered with OODB 18 by running DDL 80. OMS 42 also interfaces with object map 50 to manage the actual persistent objects referenced by PTR 44. OMS 42 further interfaces with object translation system 52
(hereinafter referred to as "OTS 52") to translate persistent objects between their primary and secondary memory representations. OTS interfaces with types 40 created by DDL 80. Finally, OMS 42 interfaces with persistent object server 54 (hereinafter
referred to as "POS Server 54") to store and retrieve the persistent objects managed by OMS 42.
POS Server 54 interfaces with RDBMS 20 using a standard Structured Query Language (SQL) interface to physically store and retrieve the persistent objects managed by OMS 42. RDBMS 20 interfaces with secondary memory storage devices 24 to
physically store and retrieve tile objects created by application 14 and managed by OODB 18.
The various modules of the present (DDL 80, OMS 42, name manager 46, demon table 48, object map 50, PTR 44, OTS 52, and POS Server 54) will now be considered in more detail.
Prior to developing an application system that interfaces with the present invention, the application developer must register the C++ classes to be used in the application system with the present invention. This is accomplished by executing the
DDL translator described below.
The DDL Translator 80 (hereinafter referred to as "DDL 80") is based on three separate application programs that are executed in sequence (see FIG. 3). DDL 80 receives as input one or more data definition language source files 26 written by the
developer of application 14. These source files 26 contain class definitions in the C++ language plus additional keywords and syntactic constructs defined by the present invention (see Table 1 for an example of such a DDL source file). DDL 80 then
extracts sufficient information from source files 26 to generate a C++ source file 40 (hereinafter referred to as "types 40"; see Table 2 for an example of such a C++ source file) containing type description information for use by OMS 42 and OTS 52, and
a set of C++ source files 38 for every class definition in the source file(s). These files are then subsequently used by the application programmer when writing, compiling, and executing C++ programs that create and manipulate instances of the classes,
as well as save or retrieve them using the present invention.
The first program in the sequence depicted in FIG. 3 is the commercially available C language preprocessor cpp 28. This program receives as input source files 26 and produces a copy of the input file(s) with all cpp directives evaluated and
expanded (expanded file 30). Use of this program in the present invention does not require any modification.
TABLE 1 __________________________________________________________________________ class ptrs : persistent // to indicate independent persistence { private: int len; // controls length of data member `mpd` // Pointers to array of data types char *[10] cpd; // constant length char *[len] mpd; // length controlled by data member `len` char *[sentinel' 0'] spd; // length terminated by hexadecimal zero boundary char *bpd; // referenced data is ignored when saved classPTR pers.sub.-- ref;
// reference To independent persistent object public: // Definition of Demon functions demon create int setup(); // creation time demon demon restore int resetup(); // fetch time demon demon commit int ready (); // commit time demon demon abort
int cleanup 1); //abort time demon }; __________________________________________________________________________
TABLE 2 __________________________________________________________________________ char *Type-Descriptions[] = { /* DDL RELEASE 0.1.5 */ /* 0-2: OCDB Classes */ "16.vertline.&.vertline.0.vertline.1.vertline.0.vertline.1.vertline.254.ve
rtline.0.vertline...vertline.&.vertline.7.vertline.0.vertline.4.vertline.1 .vertline.255.vertline.1.vertline.1.vertline.&.vertline.7.vertline.0.vertl ine.8.vertline.1.vertline.255.vertline.1.vertline.0.vertline.&",
"24.vertline.&.vertline.0.vertline.1.vertline.0.vertline.1.vertline.254.ve rtline.0.vertline...vertline.&.vertline.7.vertline.0.vertline.16.vertline. 1.vertline.255.vertline.1.vertline.1.vertline.&.vertline.7.vertline.3.vert
line.20.vertline.1.vertline.255.vertline.1.vertline.1.vertline.&.about., "8.vertline.&.vertline.7.vertline.3.vertline.0.vertline.1.vertline...vertl ine...vertline.2.vertline.&", /* 3: User Class A */
"12.vertline.&.vertline.7.vertline.3.vertline.0.vertline.1.vertline...vert line...vertline.3.vertline.&", /* 4: User Class B */ "8.vertline.&.vertline.7.vertline.3.vertline.0.vertline.1.vertline...vertl ine...vertline.4.vertline.&", /* 5: User Class
C */ "l2.vertline.&.vertline.7.vertline.3.vertline.8.vertline.1.vertline...vert line...vertline.5.vertline.&", }; Interpretation of Fields "12.vertline.&.vertline.7.vertline.3.vertline.8.vertline.1.vertline...vert line...vertline.5.vertline.&'
.vertline. .vertline. .vertline. .vertline. .vertline. .vertline. .vertline. .vertline. .vertline. .vertline. .vertline. .vertline. .vertline. .vertline. .vertline. .vertline.Index into this array of referenced data .vertline. .vertline. .vertline.
.vertline. .vertline. .vertline. .vertline.Number of instances in the array .vertline. .vertline. .vertline. .vertline. .vertline. .vertline.How to determine number of instances in array .vertline. .vertline. .vertline. .vertline. .vertline.Number of dimensions in array .vertline. .vertline. .vertline. .vertline.Offset of this pointer or PTR .vertline. .vertline. .vertline.Type of pointer .vertline. .vertline.Data type of referenced data .vertline.Size of an instance of this class
__________________________________________________________________________
The second program in the sequence is the DDL processor ddl 32. This program receives as input expanded file 30 produced by the first program, scans expanded file 30 for specific information, and generates a typeobject database 34 for use by the
third program, ddlpost 36. The ddl 32 program uses a lexical scanner based on the lexical analysis program generator lex (not shown) to scan source files 26 and return each token (syntactic unit not shown) to the main functions of ddl 32. In addition
to scanning source files 26 for specific information, ddl 32 performs full syntactic and limited semantic checking on the input file, and generates appropriate error and warning messages.
ddl 32 processes each class definition in the input file as follows. First, it scans the input tokens until it recognizes the C++ keyword "class". If the "class" keyword is found, ddl 32 continues to scan for and then extract the class name,
the name(s) of any classes from which this class is to be derived, and a keyword, "persistent", that indicates whether or not instances of this class should become "independent persistent objects" (IPO) when saved to the database. If this class is
derived from another class and does not have the "persistent" keyword, ddl 32 determines if the latter class is also a persistent class. If so, this class is marked as an persistent class. If "persistent" is not present and if this class is not derived
from a persistent class, instances of this class can still be saved to the database, but they will become "dependent persistent objects" (DPO) physically stored with an IPO. If the class(es) from which this class is to be derived has(have) not been
previously processed by ddl 32 in this file or in previous executions of DDL 80, an error message is generated.
Second, ddl 32 scans the rest of the class definition for the declarations of data members and extracts the name of the data member, the name of the data type (fundamental C++ or user-defined type, including classes), and then determines the
class's memory alignment, size, padding between it and the next data member, and its offset from the beginning of the class. ddl 32 also extracts information indicating if the data member is an array, the number of elements in the array, if the data
member is a C++ pointer, the name of the data type of the referenced data, the number of data items referenced by the pointer (which can be sp | | |
