home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / alt / sources / 2874 < prev    next >
Encoding:
Text File  |  1992-12-23  |  5.2 KB  |  138 lines
  1. Newsgroups: alt.sources
  2. Path: sparky!uunet!spool.mu.edu!news.cs.indiana.edu!umn.edu!csus.edu!netcom.com!thinman
  3. From: thinman@netcom.com (Technically Sweet)
  4. Subject: COOL: C Object-Oriented Library: part 0 of 4
  5. Message-ID: <1992Dec23.191426.10202@netcom.com>
  6. Organization: International Foundation for Internal Freedom
  7. Date: Wed, 23 Dec 1992 19:14:26 GMT
  8. Lines: 128
  9.  
  10.  
  11. Second public release.
  12.  
  13.  
  14.         COOL - C Object-Oriented Library
  15.  
  16. COOL is: Copyright 1991 by Lance Norskog - ABANDONED
  17.  
  18. I'm writing a large software project [1] and need something better
  19. than C.  Something which is absolutely as portable as C.  After looking
  20. at C++, SmallTalk, and Objective C, I gave up and wrote COOL instead.
  21.  
  22. It adds objects to C with a minimum of code-junk and no preprocessing.
  23. The implementation is as simple as is reasonable.  Object messaging,
  24. creation, and deletion are reasonably streamlined.  Little attempt has
  25. been made for high performance.  If you design for performance,
  26. you usually get software that's fast but useless.
  27.  
  28. See the man page for more information and a rudimentary coding example.
  29. See the tst?.c programs for info on exercising features.
  30.  
  31. This is released to the net for general interest, information on
  32. how a rudimentary object system works internally, and to serve
  33. as a vehicle for prototyping new OO styles.  Instead of conducting
  34. gedanken experiments about how objects should work, or spending
  35. years designing new languages & compilers, now you can implement 
  36. your variant and play around with it coding up your favorite examples.
  37.  
  38. Inheritance:
  39. Multiple inheritance is implemented.  No ambiguous methods are
  40. allowed in a class definition.  Inheritance is implemented
  41. essentially as multiple objects with one name; these objects
  42. can call SELF with methods they themselves don't implement.
  43.  
  44. Porting:
  45.  
  46. Objects are methods are given as strings or magic ID numbers.  
  47. The library contains routines which transform strings to IDs.
  48. The object and method ID spaces are both segmented into two
  49. pieces.  Object numbers are an array index and a generation
  50. number.  Method numbers are an array index and a parent index.
  51.  
  52. These number spaces will have to resegmented for your computer.
  53. The release includes macros for 386 UNIX, and assumes that
  54. string addresses are in the data segment or in the stack
  55. local area.  The object and method spaces pack their two numbers
  56. avoiding these bit addresses, so that the library can distinguish
  57. between a string and pre-cached ID on the fly.
  58.  
  59. This implementation is mostly bogus.  Instead, it should
  60. have a magic marker (I prefer 0xdeadbeef) at the beginning
  61. of an object.  But, encoding the generation number in
  62. the object is still worthwhile.
  63.  
  64. Also, the exception system uses setjmp and longjmp.  If yours
  65. don't work, you don't get catchable exceptions.  The object 
  66. library uses exceptions, but doesn't catch them, so it will
  67. work anyway.
  68.  
  69. Beyond that, any 32-bit machine should be able to run COOL.
  70. With the above magic marker trick, it should run under DOS
  71. and Windows also.
  72.  
  73. Benchmarks:
  74.  
  75. 'bench.c' makes counts an integer from 0 to a very large number
  76. in 6 different ways.  The first way uses canonical safe message
  77. calls.  The second way uses unsafe cached messaging.  The remaining
  78. ways use native C in various ways.  A case statement and a
  79. procedure call is used as a standard against which to measure 
  80. messaging performance.
  81.  
  82. 'benchall' compiles the benchmark and the library with the
  83. native C compiler and with GCC, both with and without optimization,
  84. and runs the benchmark.
  85.  
  86. The files out.unix386 and out.xenix contain the benchmark results
  87. on those operating systems.
  88.  
  89. Ports also included for 68020 and SPARC SUNs, and VMS.
  90. These ports, and some bug fixes, where contributed by Henk
  91. Davids from Germany and Nicolas ?? from France.
  92.  
  93. This is the fourth release, patchlevel 4.  Patchlevel 2 was
  94. Nicolas' port to SUNs and bug fixes, which he posted to
  95. alt.sources.  These changes have been incorporated.
  96. Patchlevel 4 didn't do grandparent classes right,
  97. and I've added components, overloading,
  98. and the Scheme interface files.  Cool_elk.c allows
  99. ELK Scheme to use COOL as an extension interface.
  100. Cool_scm.c does likewise with SCM Scheme.  The beauty
  101. part is that you just write your extensions in C
  102. as classes, test them, then link them with Scheme.
  103. You don't have to write any custom code to bridge the two.
  104.  
  105. Cool_scm.c implements overloaded operators.  Cool_elk
  106. does not.  Overloaded operators are not well documented,
  107. and the implementation is of necessity iffy because
  108. of the coruscating plasticity of C's calling sequence.
  109.  
  110. Please send me all updates, ports, and benchmark results you can.
  111. COOL is a basic technology for my VR window system project,
  112. and I am the maintenence person.  I may rewrite it for 
  113. efficiency at some point.
  114.  
  115. Acknowledgements:
  116.     Nicolas ?? at Electricite De France <nicolas@cli52or.edf.fr>
  117.         for SUN-3 & SUN-4 ports and bug fixes
  118.     Henk Davids <hdavids@mswe.dnet.ms.philips.nl>
  119.         for SUN-4 port and bug fixes
  120.     David L. Williams <dlw@atherton.com>
  121.         for NeXT port
  122.  
  123. Enjoy!
  124.  
  125. Lance Norskog
  126. thinman@netcom.com
  127.  
  128. [1] A Virtual Reality window system based on Scheme & C extensions.
  129. Something like NeWS...
  130.  
  131. p.s.    tst4 is supposed to cause a core dump.  That's how
  132.     exceptions work.
  133. -- 
  134.  
  135. Lance Norskog
  136.  
  137. Data is not information is not knowledge is not wisdom.
  138.