Replying to a message of Jonathan de Boyne Pollard to Andreas Kaiser:

 JdBP>>>                           What is DirectToSOM C++ ?

 AK>> Please note that DTS was dropped from the SOM 3.0 release 

 JdBP> Not possible, for the very simple reason that DTS C++ is a function
 JdBP> of the C++ compiler, not the SOM libraries.  The C++ compiler
 JdBP> hasn't changed. 

If you stick to C++ and use nothing but C++ you may be correct (however - I
dont't remember - doesn't DTS need at least som.hh?). However if you want
to use some of the SOM frameworks, DSOM or want to interface to some other
plain SOM based implementation you need a DTS emitter who translates IDL to
the DTS *.hh include files. Such an emitter does _not_ ship with SOM 3.0.

Quoted from SOM 3.0 README:

  "SOMobjects 3.0 does not support Direct-To-SOM.  The following notes
   are provided to assist users who created DTS C++ code using support
   provided by earlier releases, and who now want to migrate this DTS C++
   code to C or native mode C++ code that uses the C or native mode C++
   bindings provided by the SOMobjects 3.0 product."

The notes more or less say "rewrite DTS code to use plain native C++
bindings".

 JdBP> I haven't heard screams and shouts
 JdBP> about Workplace Shell refusing to run when people install SOM 3.0,
 JdBP> so I assume that that is _not_ the case. 

The only place were I have a problem with 3.0 is VisualAge Smalltalk
showing a trap popup late in the exit phase. However there _are_
differences in representation. The enum data type size is different, for
example. DSOM 3.0 is not interoperable with DSOM 2.1. And more of this
kind.

 JdBP> If it's something as simple as the DTS C++ headers in the new SOM
 JdBP> libraries being wrong, or unavailable, this is not news.

There aren't any. Neither *.hh includes, not an emitter to produce them.
Nor another source for a supposedly "working" DTS (as it has been
with the 2.1 and the 3.0 beta).

BTW: SOM 3.0 is available for free, downloadable at IBM WWW. Check yourself.

 AK>>                            Corba comes a lot closer to the language
 AK>> principles of C++ wrt. memory management of strings and sequences,
 AK>> naming and exception handling.

 JdBP> Than DirectToSOM C++, or than the SOM C++ language bindings (_not_
 JdBP> the same thing by a long stretch) ?

Doesn't matter. The sequence and string data types are the same for
DTS and for SOM C++. They simple do not support constructor/destructor
mechanisms, beeing just simple C structs or char pointers. The SOM
exception handling is not mapped to C++ exception handling. In Corba 2.0
C++ bindings, strings and sequences map to C++ classes with a (partially)
reasonable memory management and Corba exceptions map to C++ exceptions,
not just to a second return code.

Unless however you completely forget about SOM and IDL and just use the
calling convention and linkage mechanisms of DTS to glue your classes
together. You are free to do this, however such code voids DSOM and other
language interfaces. I wouldn't call this SOM, it may be viewed as just
another way your C++ compilers handles virtual function calls.


Bye, Andreas!

--- FleetStreet 1.18 NR