ZZ>
  >   >> one of the big drawbacks of C++
  >   >> is that you almost always have to have the source to
extend a class.
  >
  > thats not true. just put your class into a DLL and _Export
  > it. The client just needs the header file.
ZZ>

  AHEM!

ZZ>
  > ok. you must have the same compiler & compiler version ...
ZZ>

  Precisely.  (That mechanism is not universally available on all
  compilers, either.)

  Anyway, class libraries are written for OTHER PEOPLE to use.

  If I compile my classes on Borland C+ 1.5 and you use IBM CSet++ 3.0,
  we are stuck for using each others' classes, be they in DLLs or not.

  Even though Borland C++ has the ability to apply the __export keyword
  to a whole class, it only works when called from an application
  written in Borland C++, and only *that* version of Borland C++.

  Also, the implementation of the virtual function tables and the
  calling conventions (CSet++ uses _Optlink for member functions), mean
  that we cannot even exchange object code; we *must* exchange source to
  use each other's class libraries.

ZZ>
  >  JdeBP> After all, if you (as a library vendor) give me a header file and a
  >  JdeBP> DLL, I can use, subclass, and generally mess about with your classe
  >  JdeBP> without the source, if they are SOM classes.
  >
  > thats exactly as in C++.
ZZ>

  Except that in C++ it's not implemented in a fashion useful to anyone
  in the real world.

  Whereas SOM classes were designed to be portable across compilers (and
  even across languages).

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 2.01wb