Mapping between EXPRESS and C++
The different types in an EXPRESS schema are mapped to C++ in the following way:
Table 1: Mapping of EXPRESS constructs to C++
EXPRESS |
C++ |
---|---|
Entity |
Class |
Complex entity |
Class with name equal to the complex entity name except that the '+' delimiter is substituted with '_'. |
Entity with multiple inheritance |
Class with multiple inheritance |
Select |
If all the alternatives of the select are entities, it is mapped to dbInstance which is the common superclass for all C++ classes representing entities. Otherwise the select is mapped to cppSelect which is identical to the select struct used in SDAI. |
Enumeration |
typedef enum {.., .., } <Enumeration name>; |
Integer |
EDMLONG |
Real |
Double |
Logical |
typedef enum {logicalFalse = 0, logicalUnknown, logicalTrue} logical; |
Boolean |
Bool |
String |
char * |
Array |
template <typename ArrayElement> |
List, Set and Bag |
Subtypes of class dbLinkedAggregate. |
The C++ classes have, in addition to constructors, put and get methods for each explicit attribute. Derived and inverse attributes have only get methods as their values are computed and set automatically.
Every C++ class that represents an EXPRESS entity inherits the class dbInstance. The dbInstance class refer to the attribute buffer where attribute values are stored, and contains the unique object identifier in the EDM database. When a C++ object is created in the client memory, the unique database object identifier is set to NULL. When the C++ EXPRESS API has created a corresponding object in the EDM database, the unique database object identifier gets the correct value from the database.
Using the OIM (objects in memory) pattern of the C++ EXPRESS library, it is possible to link objects together forming deep structures in the client memory before storing the objects in the database. At a certain point in time one can store all objects in the database with one single function call. The inverse attributes are not assigned when using OIM pattern. That will happen when the objects are written to database, and when the objects are read back to memory at a later stage, the inverse attributes are correctly assigned. The same pattern applies for the derived attributes.