bryan@UUNET.UU.NET (Bryan Boreham) (07/12/89)
Several people have asked about non-Zortech library support for ET++. For those that have the source, the AT&T libraries will do just fine, as long as you compile them with g++. Doug Lea has offered beta-test streambuf-compatible libraries, and I'm sure they work quite well, but it really can't be desparately difficult to write your own. The outline of what to do is in Stroustrup, and you can fudge round the difficult bits by using sprintf, etc., if all you want is to get ET++ working. I'm not going to make any changes to ET++ to make it work with libg++ 1.35. The streams there don't have a way of declaring that the buffer they are printing to has overflowed. Maybe the most GNU-like wayy to proceed is to extend libg++ streams so they can print into obstacks? On a more positive note, I made the necessary changes to enable ET++ applications to be dynamically linked. All the demos except for "draw" now work in this way for me, saving acres of disk space. Debugging is impossible, though. The patches for dynamic linking are available by mail to anyone who understands that they may not work perfectly yet. I will post them here once I feel happier about them. If someone knows a good way to get gdb to co-operate in the dynamic linking, please get in touch. Also, if someone knows an existing scheme for indexing the routines in each .o file, I'd like to hear it. Currently the system will look in file "MyClass.o" if it sees a call to MyClass::MyClass, which works most of the time, but fails in the general case. I think that with a lot of hard work, we can have a free "C++ interactive development enviroment", where the programmer can single-step through her code in a window, then edit it and have it compiled and dynamically linked back into the running application. Collaborators in this project would be most welcome. Bryan.