The (highly unofficial) FIDONET OS2PROG C++ compiler pros and cons list 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� What is DirectToSOM C++ ? 컴컴컴컴컴컴컴컴컴컴컴컴� To understand what DirectToSOM C++ is, you must first understand what SOM, IBM's System Object Model, is. SOM is a language-independent foundation for classes and objects. It defines a run-time environment to use for creating, destroying, instantiating, and generally manipulating classes. It uses CORBA IDL for writing class definitions. One idea behind SOM is that class support need not be language or compiler specific. Most object oriented languages until now have had proprietary runtimes for their class systems. SOM provides an open binary standard interface for class support at runtime which any language can use, and the SOM toolkit contains tools to translate class specifications in IDL into "language bindings" that allow those languages to use and implement SOM classes. Any language that can call functions through pointers can use SOM, so using SOM classes is even possible in C. The C language bindings use an incredible number of macros to try to make the class system seem as sensible as possible, and to try to hide all of the pointers used for method accesses. Another idea behind SOM is to separate class implementation and class use by providing a binary layer that they both adhere to. SOM sets several rules, which, if they are abided by, mean that it is possible to change the implementation of a class and add new data or function members without affecting the client in any way. DirectToSOM is the logical next step to take with SOM. Instead of using syntactically obscure language bindings, the compiler takes your source written in your native language and compiles it into object code that uses the SOM runtime for class support, instead of a proprietary class runtime specific to that compiler or that language. A DirectToSOM C++ compiler can take normal C++ source and compile it to use the SOM runtime directly, instead of the proprietary C++ runtime. This means that it is possible to take a normal C++ class and make it into a SOM class simply by compiling with the appropriate compiler switches. Another route is to change the C++ class definition so that it inherits from an existing SOM class, such as the predefined SOMObject class. Here, for example, is such a SOM class written in DTS C++ : class BankAcount : public SOMObject { public: long balance ; } ; int main ( int, char ** ) { BankAccount account ; } It looks just like C++, doesn't it ? Compile it, though, and you should even be able to use it from SmallTalk. For a C++ programmer, DirectToSOM C++ is the easiest way to use SOM, because there is very little new to learn. You just write C++ code as you always have done. What are interesting, though, are the advantages that DTS C++ has over normal C++ because it uses SOM. Certainly, DTS C++ gives (to coin a phrase) "a better C++ than C++" in a lot of respects. In normal C++, two C++ compilers cannot share code at any level below source level. There are many reasons for it being impossible, including the facts that most C++ compiler vendors use different name mangling schemes, different parameter passing conventions, different run-time support functions in the standard library, and different run-time data structure layouts for things like virtual function tables and inheritance. This means that all C++ class libraries are required either to be compiled with every individual C++ compiler that they wish to support, or to be distributed in source form. Two DirectToSOM C++ compilers, however, can share code at the binary level, since SOM is a binary standard. You can compile a DTS C++ class into a dynamic link library and distribute it; and as long as the class definition is shipped along with it, any DTS C++ compiler (or even any other SOM-capable language) can use that class. There are no name mangling issues to worry about when compiling a DTS C++ class into a DLL either. A DTS C++ class requires exactly three export entries, none of which have mangled names. SOM comes with several such class libraries (or "frameworks") already. The Persistence, Replication, and Distribution frameworks are little more than libraries of SOM classes, and are distributed as a suite of DLLs, along with IDL class definitions so that people can use them. Other features of DTS C++ not found in C++ but familiar to object oriented programmers who use other languages are metaclasses and attributes. Classes are "first class objects" in SOM, meaning that every class is itself an instance of another class, the "metaclass". Metaclasses have methods that are used for various things, and metaclass programming with DTS C++ opens up a whole new area at runtime not normally available to the C++ programmer, including such abilities as adding new methods to classes at runtime, and controlling class instance placement and construction. Attributes provide more control over instance data for classes, such as the ability to make it read-only. Here is the above example, with an attribute : class BankAcount : public SOMObject { public: long balance ; #pragma SOM_Attribute(balance) } ; int main ( int, char ** ) { BankAccount account ; account.balance = 100 ; } One of the more interesting things possible with attributes are that it is possible for a class to intercept all read and write accesses to an attribute, by providing "get" and "set" member functions for that attribute, which are invisible to the client. DTS C++ also has a more extensive run-time type information (RTTI) system than C++. All classes are actual physical entities at run-time with SOM, and not mere compile-time abstractions. This allows you to traverse the class hierarchy at run-time and find out a lot of information about instance types. DTS C++ compilers also allow you to use C++ language facilities that aren't normally part of SOM, such as function overloading, exception throwing, and abstract base classes. DTS C++ compilers map these C++isms onto SOM as gracefully as possible (if non-C++ SOM client tries to instantiate an abstract base class, a run-time error results, for example). This is especially useful where DTS C++ is being used as an enhancement to C++ instead of as as a means of using SOM itself. This could be the case where the greater separation between class implementation and class use that SOM affords is desirable in a C++ application, for instance. SOM is already used by several applications. The Workplace Shell is almost entirely a set of SOM classes (such as WPFolder, WPProgram, and WPShadow), and all WPS extensions are new classes derived from existing WPS classes. IBM Works, and several of the BonusPak utilities like Ultimail rely on SOM. SOM is the intended basis for the Taligent Application Frameworks as well. DirectToSOM C++ was co-developed by MetaWare and IBM. MetaWare is currently on to the second release of its DTS C++ compiler, High C++ version 3.31. IBM is currently beta testing its first DTS C++ compiler, CSet++ version 3.0. There has been no word as yet from Watcom on when it will support DirectToSOM C++. See the Pros and Cons list for contact information. � JdeBP � � (c) Copyright 1995 All Rights Reserved. � � JdeBP@donor2.demon.co.uk FIDONET 2:440/4.0 �