The SOM Compiler operates in two phases:
Each binding file is generated by a separate emitter program. Setting the SMEMIT environment variable determines which emitters will be used, as described below. Note: In the discussion below, the <filesystem> is determined by default from the name of the source .idl file with the ".idl" extension removed. Otherwise, a "filestem" modifier can be defined in the .idl file to specify another file name (see "Modifier statements" above).
Note: If changes to definitions in the .idl file later become necessary, the SOM Compiler should be rerun to update the current implementation template file, provided that the c or xc emitter is specified (either with the -s option or the SMEMIT environment variable, as described below). For more information on generating updates, see "Running incremental updates of the implementation template file" later in this chapter.
The emitters for the C language produce the following binding files:
<filestem>.c
This is a template for a C source program that implements a class's methods. This will become the primary source file for the class. (The other binding files can be generated from the .idl file as needed.) This template implementation file contains "stub" procedures for each method introduced or overridden by the class. (The stub procedures are empty of code except for required initialization and debugging statements.)
After the class implementer has supplied the code for the method procedures, running the c emitter again will update the implementation file to reflect changes made to the class definition (in the .idl file). These updates include adding new stub procedures, adding comments, and changing method prototypes to reflect changes made to the method definitions in the IDL specification. Existing code within method procedures is not disturbed, however.
The .c file contains an #include directive for the .ih file, described below.
The contents of the C source template is controlled by the Emitter Framework file <SOMBASE>/include/ctm.efw. This file can be customized to change the template produced. For detailed information on changing the template file see the Emitter Framework Guide and Reference.
This is the header file to be included by C client programs (programs that use the class). It contains the C usage bindings for the class, including macros for accessing the class's methods and a macro for creating new instances of the class. This header file includes the header files for the class's parent classes and its metaclass, as well as the header file that defines SOM's generic C bindings, som.h.
This is the header file to be included in the implementation file (the file that implements the class's methods-the .c file). It contains the implementation bindings for the class, including:
The emitters for the C++ language produce the following binding files:
<filestem>.C (for AIX) or <filestem>.cpp (for OS/2)
This is a template for a C++ source program that implements a class's methods. This will become the primary source file for the class. (The other binding files can be generated from the .idl file as needed.) This template implementation file contains "stub" procedures for each method introduced or overridden by the class. (The stub procedures are empty of code except for required initialization and debugging statements.)
After the class implementer has supplied the code for the method procedures, running the xc emitter again will update this file to reflect changes made to the class definition (in the .idl file). These updates include adding new stub procedures, adding comments, and changing method prototypes to reflect changes made to the method definitions in the IDL specification. Existing code within method procedures is not disturbed, however.
The C++ implementation file contains an #include directive for the .xih file, described below.
The contents of the C++ source template is controlled by the Emitter Framework file <SOMBASE>/include/ctm.efw. This file can be customized to change the template produced. For detailed information on changing the template file see the Emitter Framework Guide and Reference.
This is the header file to be included by C++ client programs that use the class. It contains the usage bindings for the class, including a C++ definition of the class, macros for accessing the class's methods, and the new operator for creating new instances of the class. This header file includes the header files for the class's parent classes and its metaclass, as well as the header file that defines SOM's generic C++ bindings, som.xh.
This is the header file to be included in the implementation file (the file that implements the class's methods). It contains the implementation bindings for the class, including:
Other files the SOM Compiler generates:
<filestem>.hh
This file is a DirectToSOM C++ header file that describes a SOMobjects class in a way appropriate to DTS C++. When running this emitter, you must include the noqualitytypes command-line modifier for the -m optionof the SOM Compiler command sc or somc.
This file is used by the linker to package a class as a library. To combine several classes into a single library, you must merge the exports statements from each of their .def files into a single .def file for the entire library. When packaging multiple classes in a single library, you must also write a simple C procedure named SOMInitModule and add it to the export list. This procedure should call the routine <className>NewClass for each class packaged in the library. The SOMInitModule procedure is called by the SOM Class Manager when the library is dynamically loaded.
This file is used by the linker to package a class as a library. To combine several classes into a single library, you must merge the exports statements from each of their .exp files into a single .exp file for the entire library. When packaging multiple classes in a single library, you must also write a simple C procedure named SOMInitModule and add it to the export list. This procedure should call the routine <className>NewClass for each class packaged in the library The SOMInitModule procedure is called by the SOM Class Manager when the library is dynamically loaded.
See Chapter 7 for a discussion on the Interface Repository.
SOM users can extend the SOM Compiler to generate additional files by writing their own emitters. To assist users in extending the SOM Compiler, SOM provides an Emitter Framework a collection of classes and methods useful for writing object-oriented emitters that the SOM Compiler can invoke. For more information, see the Emitter Framework Guide and Reference.
Note re: porting SOM classes: The header files (binding files) that the SOM Compiler generates will only work on the platform (operating system) on which they were generated. Thus, when porting SOM classes from the platform where they were developed to another platform, the header files must be regenerated from the .idl file by the SOM Compiler on that target platform.