View source for A Look at What's New in SOM 2.1

Written by [[Gordon Zeglinski]]

==A Look at What's New in SOM 2.1==

I finally got the SOM 2.1 toolkit. In this issue, we'll look at its new features and then compare its bench mark results with those of SOM 2.0.

Before we move on, let's look at some miscellaneous details. I strongly recommend that anyone installing SOM 2.1 over SOM 2.0 edit their CONFIG.SYS files and then reboot OS/2 to disable the 2.0 toolkit before installing. This will make installation much simpler and helps insure it works the first time. The installation is pretty much the same as that of the 2.0 toolkit. Outside of a small install manual, the toolkit no longer contains any printed documentation. The CD contains a set of PostScript files one can print to make manuals, and some FrameView files. This is where I get really annoyed at IBM. They only ship a Windows and AIX version of the on-line documentation viewer! This means that you have to run WIN-OS/2. Thus, losing all the resources it uses while running the memory hungry development tools. This quickly makes 20 megs of RAM look pretty small.

==What's New in SOM 2.1==

There are many new features in the 2.1 toolkit. Overall I think a fair summary would be saying it's more C++ like but still retains all of the OOP abilities from the 2.0 version. Direct To SOM (DTS) C++ compiler support is now included along with support for the 32 bit TCP/IP stack available in TCP/IP 2.0 for OS/2 and the Internet Access Kit in Warp. The use of somInit and somUninit is no longer recommended. Instead, a more C++ like method of doing initializers is recommended. The methods somDefaultInit, somDefaultConstCopyInit and somDestruct have been added. These methods correspond to the default constructor, copy constructor and destructor in C++. In addition there's now support for an assignment method. The somDefaultConstAssign method provides this mechanism and is equivalent to the operator = in C++.

In our previous SOM articles, metaclasses were used to provide class data and constructors. Recall that class data is analogous to static data in C++. SOM 2.1 now supports staticdata variables. When this is combined with the new method of specifying constructors/initializers, metaclasses are rarely needed now. The modifiers somallocate and somdeallocate allow user defined memory allocation and deallocation functions to be used when creating an instance of the object. This is similar to overloading the new and delete operators in C++. This concludes our brief look at what's new in SOM 2.1. I haven't covered any of the new features in DSOM because we haven't previous looked at DSOM.

==Benchmarking SOM 2.1==

The SOM 2.1 documentation claims that SOM 2.1 is faster than SOM 2.0. In this section, we'll present the revamped SOM bench mark code and compare the results of running the SOM 2.1 benchmark with those previous obtained for SOM 2.0 and C++.

Let's start by looking at the new SOMBENCH.IDL file.


 #ifndef __SOMBENCH_h__
 #define __SOMBENCH_h__
 
 #include <somobj.idl>
 
 //-----------------------------------
 // SOMfoo
 //   Our SOM based test object
 //-----------------------------------
 
 
 interface SOMFoo : SOMObject
 {
 
    attribute long Count;	    // Stores the Count Data
 
    void IncrementCount();	   //procedure
    void OffIncrementCount();	   //offset
    void LookIncrementCount();    //lookup
 
 
 #ifdef __SOMIDL__
 implementation
 {
     releaseorder: _get_Count,_set_Count,IncrementCount,\
 			OffIncrementCount,LookIncrementCount;
 
     IncrementCount: procedure;
     LookIncrementCount:namelookup;
 
     callstyle=oidl;
     filestem = sombench;
     somDefaultInit: override;  // initialize instance
 variables to 0
     somDestruct:override; // just for fun
 
 };
 #endif /* __SOMIDL__ */
 };
 
 #endif /* __SOMBENCH_h__ */

There's no major difference between this version and the previous version of sombench. In fact, the only difference is that somInit and somUnitit have been replaced by somDefaultInit and somDestruct. Even though the definition isn't much different, the bench mark results are different. The following table shows the results of the benchmarks.

{| border="1"
! Resolution Type
! C++
! SOM 2.0
! SOM 2.1
|-
| procedure
| 219
| 656
| 844
|-
| virtual/offset
| 281
| 719
| 1000
|-
| name lookup macro
| n/a
| 22031
| 1031
|-
| name lookup explicit
| n/a
| 175031
| 130062
|}

<small> Table 1. Comparison of call type overhead between C++, SOM 2.0 and SOM 2.1 </small>

The times indicated are in milliseconds for 1000000 calls to a given function. The results for SOM 2.1 show that there are some speed increases and some decreases. In particular, the name lookup resolution method shows dramatic speed improvements.

==Profile Files Revisited==

To explore the new initialization methods, we will once again look at the "ini file" manipulation object. The definition for the revised SOM_CPPini file follows.

 #ifndef __SOMCPP_idl__
 #define __SOMCPP_idl__
 
 #include <somcls.idl>
 
 //-----------------------------------
 // SOMfoo
 //   Our SOM based test object
 //-----------------------------------
 
 interface ProfileFile;
 
 interface SOM_CPPini : SOMObject
 {
    typedef unsigned long ULONG;
    typedef sequence<char> buffType;
 
 
    void OpenFile(in string FileName);
    ULONG GetError();
 
    unsigned long GetHandle();
    void SetHandle(in unsigned long H);
 
    void  WriteString(in string App,in string Key, in string String);
 	   // write a string
 
    void  WriteData(in string App, in string Key,in buffType Buff,
 	   in ULONG BLen);	  // write the Buffer
 
    void  WriteInt(in string App,in string Key,in long Num);
 	   // write an "int"
 
 
 
    ULONG GetDataSize(in string App,in string Key);
 	   // return the lenght of the data
 
    void  GetData(in string App,in string Key,in buffType Buff,
 	   inout ULONG BufMax);     // return the data in Buff
 
    ULONG GetString(in string App,in string Key,in buffType Buff,
 	   in ULONG BufMax, in string DefArg);
 	   // return the String in Buff, defaults to DefArg if App/Key not
 	   // present
 
    ULONG GetStringNoDef(in string App,in string Key, in buffType Buff,
 	   in LONG BufMax);	    // return the String in Buff
 
    long  GetInt(in string App,in string Key,in long DefArg);
 	   // return the "int" in App/Key or the DefArg if App/Key
 	   // not present
 
    long  GetIntNoDef(in string App,in string Key);
 	   // return the "int" in App/Key
 
    void ProfileFileFromName(inout somInitCtrl ctrl, in string name);
    void ProfileFileFromHandle(inout somInitCtrl ctrl, in ULONG H);
 
 #ifdef __SOMIDL__
 implementation
 {
 
     ProfileFile INIFile;
 
     releaseorder: GetHandle,SetHandle,GetError,OpenFile,
                   \WriteString,WriteData,WriteInt,GetDataSize,GetData,
                   \GetString,GetStringNoDef,GetInt,GetIntNoDef,
                   \ProfileFileFromName,ProfileFileFromHandle;
 
     callstyle=oidl;
     filestem = somcpp;
     somDefaultInit: override;    // initialize instance variables to 0
     somDestruct:override;	   // just for fun
     ProfileFileFromHandle:init;
     ProfileFileFromName:init;
 
     passthru C_xh_after=   "#define INCL_WINSHELLDATA" \
 				   "#include <os2.h>" \
 				   "#include \"iniflobj.h\"";
 
 };
 #endif /* __SOMIDL__ */
 };
 
 #endif /* __SOMBENCH_h__ */

Additions to the interface definition are marked in bold. The revised definition has the functions ProfileFileFromName and ProfileFileFromHandle declared as initializers. This allows us to use a more C++ like method of creating an instance of SOM_CPPini. Following is the revised main routine for the object test file.

 #include "somcpp.xh"
 #include <stdio.h>
 
 void main(){
    int i;
 
    SOM_CPPini *Prf=new SOM_CPPini("test.ini");
 
    Prf->WriteInt("App","Key",10);
    i=Prf->GetIntNoDef("App","Key");
 
    printf("i= %i\r\n",i);
 
    delete Prf;
 }
 
The new SOM_CPPini("test.ini") operation will create an instance of the SOM object SOM_CPPini and then call the initializer ProfileFileFromName. The SOM compiler will map each SOM initializer on to a C++ constructor provided the arguments to the SOM methods are different. Basically, this is the same rule that is imposed on C++ constructors; no two constructors can have the same arguments.

==Wrapping Things Up==

We now come to the end of our peek at SOM 2.1. The executables, which should run under WARP, and source code to these examples is included with this issue. We have briefly looked at the new features in SOM 2.1, benchmarked SOM 2.1 using the simple test code, and then explored the new methods used to initialize SOM objects. We have seen that many of the new features allow SOM objects to be more C++ like.

In the next issue, I hope to start looking at DSOM. I think DSOM/COBRA have the potential to radically alter the way client/server programming is done. For this reason, and my on going experience with programming INTERcomm and AdeptXBBS, the look at DSOM will be heavily skewed towards client/server type scenarios.

[[Category:SOM Articles]]