OS/2 Shareware BBS: 14 Text/14-Text.zip/proscons.zip/dts.txt

Text File | 1995-03-15 | 8KB | 166 lines

   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. «
   » [e-mail]                      FIDONET 2:440/4.0 «