To obtain a pointer to a procedure using offset resolution, the C/C++ usage bindings provide the SOM_Resolve and SOM_ResolveNoCheck macros. The usage bindings themselves use the first of these, SOM_Resolve, for offset-resolution method calls. The difference in the two macros is that the SOM_Resolve macro performs consistency checking on its arguments, but the macro SOM_ResolveNoCheck, which is faster, does not. Both macros require the same arguments:
SOM_Resolve(<receiver>, <className>, <methodName>) SOM_ResolveNoCheck(<receiver>, <className>, <methodName>)
where the arguments are as follows:
receiver
These two names (className and methodName) must be given as tokens, rather than strings or expressions. (For example, as Animal rather than "Animal".) If the symbol SOM_TestOn is defined and the symbol SOM_NoTest is not defined in the current compilation unit, then SOM_Resolve verifies that receiver is an instance of className or some class derived from className. If this test fails, an error message is output and execution is terminated.
The SOM_Resolve and SOM_ResolveNoCheck macros use the procedure somResolve to obtain the entry-point address of the desired method procedure (or raise a fatal error if methodName is not introduced by className). This result can be directly applied to the method arguments, or stored in a variable of generic procedure type (for example, somMethodPtr) and retained for later method use. This second possibility would result in a loss of information, however, for the reasons now given.
The SOM_Resolve or SOM_ResolveNoCheck macros are especially useful because they cast the method procedure they obtain to the right type to allow the C or C++ compiler to call this procedure with system linkage and with the appropriate arguments. This is why the result of SOM_Resolve is immediately useful for calling the method procedure, and why storing the result of SOM_Resolve in a variable of some "generic" procedure type results in a loss of information. The correct type information can be regained, however, because the type used by SOM_Resolve for casting the result of somResolve is available from C/C++ usage bindings using the typedef name somTD_<className>_<methodName>. This type name describes a pointer to a method procedure for methodName introduced by class className. If the final argument of the method is a va_list, then the method procedure returned by SOM_Resolve or SOM_ResolveNoCheck must be called with a va_list argument, and not a variable number of arguments.
Below is a C example of using SOM_Resolve to obtain a method procedure pointer for method "sayHello", introduced by class "Hello", and using it to invoke the method on "obj." (Assume that the only argument required by the "sayHello" method is the Environment pointer.)
somMethodProc *p; SOMObject obj = HelloNew(); p = SOM_Resolve(obj, Hello, sayHello); ((somTD_Hello_sayHello)p) (obj, somGetGlobalEnvironment());
SOM_Resolve and SOM_ResolveNoCheck can only be used to obtain method procedures for static methods (methods that have been declared in an IDL specification for a class) and not methods that are added to a class at run time. See the System Object Model Programming Reference for more information and examples on SOM_Resolve and SOM_ResolveNoCheck.