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.