Article # 79, added by Geoworks, historical record
| first | previous | index | next | last |

Why is C++ not supported in the SDK?




Question:
Why doesn't the GEOS SDK support C++?

Answer:
I'll try to explain why it isn't as easy as just linking a
Borland C++ object file to the GEOS libraries to generate a
GEOS object oriented application.

When we were developing our user interface software we chose
a particular implementation of objects, classes, message
passing, etc. We made these choices because they allowed us
to do some things that were required to implement generic
user-interface objects that would transform themselves into
specific user-interface objects. Doing this requires a form
of multiple inheritance that is not supported in most C++
compilers.

C++ is an object-oriented approach to C that is implemented
by the compiler, and not by the system. This is why C++
compilers exist for UNIX (as an example) which does not
provide any sort of system level objects. All of the support
is done in the compiler.

When you send a message to an object in C++, that "send" is
bound to a piece of code that ties directly into the
message-handler for the object. When you link to C++ objects
which are defined in libraries (eg: in a user-interface
library) that "send" is tied directly to an entry point in
that library.

Now consider the problem of a specific user-interface. You
want to send a message to an object. This message may be
handled by the generic object (which could probably be
easily interfaced to C++ because the handler is known at the
time your program is linked). This message may be handled by
the specific user interface (or it may not). This is a
problem because the specific user interface is not available
at the time you link your program and therefore the linker
cannot link your message to a specific user-interface
routine (as C++ requires).

The message may also be handled by the visual objects which
implement the generic user interface. If you knew that this
was the case you could probably link to that library, but
since the visual representation is determined by the
specific UI you really can't.

So the problem is this: C++ requires that the
compiler/linker can *know* what routine will actually be
called by sending a message to an object. This is not
possible when interacting with GEOS user-interface objects.

Having made this choice for our user-interface objects, we
added support for these sorts of objects to the operating
system and these sorts of objects are now used throughout
our system.

Most of the objects in our system don't make use of this
ability which is so integral to the specific UI so we could
probably create C++ libraries for things like the Graphics-
Object library (and others).

Unfortunately since we can't easily provide C++ libraries to
allow interaction with our user-interface objects, we have
chosen not to support C++ at this time. We may find a way to
make this stuff work (by providing class libraries for
objects which will reside between the application and the
user-interface and which will send off messages to the user
interface object using the GEOS model of sending messages)
but it was a significant enough task that we have chosen to
put it off for another time.