When declaring an object variable, an object interface name defined in IDL is used as the type of the variable. The exact syntax is slightly different for C vs. C++ programmers. Specifically,
<interfaceName> obj ;
declares "obj" to be a pointer to an object that has type <interfaceName>. In SOM, objects of this type are instances of the SOM class named <interfaceName>, or of any SOM class derived from this class. Thus, for example,
Animal obj;
declares "obj" as pointer to an object of type "Animal" that can be used to reference an instance of the SOM class "Animal" or any SOM class derived from "Animal". Note that the type of an object need not be the same as its class; an object of type "Animal" might not be an instance of the "Animal" class (rather, it might be an instance of some subclass of "Animal" - the "Cat" class, perhaps).
All SOM objects are of type SOMObject, even though they may not be instances of the SOMObject class. Thus, if it is not known at compile time what type of object the variable will point to, the following declaration can be used:
SOMObject obj;
Because the sizes of SOM objects are not known at compile time, instances of SOM classes must always be dynamically allocated. Thus, a variable declaration must always define a pointer to an object.
Note: In the C usage bindings, as within an IDL specification, an interface name used as a type implicitly indicates a pointer to an object that has that interface (this is required by the CORBA specification). The C usage bindings for SOM classes therefore hide the pointer with a C typedef for <interfaceName>. But this is not appropriate in the C++ usage bindings, which define a C++ class for <interfaceName>. Thus, it is not correct in C++ to use a declaration of the form:
<interfaceName> obj ;
Note: If a C programmer also prefers to use explicit pointers to <interfaceName> types, then the SOM Compiler option -maddstar can be used when the C binding files are generated, and the explicit " *" will then be required in declarations of object variables. (This option is required for compatibility with existing SOM OIDL code. For information on using the -maddstar option, see "Running the SOM Compiler" in Chapter 4, "SOM IDL and the SOM Compiler.")
Users of other programming languages must also define object variables to be pointers to the data structure used to represent SOM objects. The way this is done is programming-language dependent. The header file "somtypes.h" defines the structure of SOM objects for the C language.