home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 18052 < prev    next >
Encoding:
Text File  |  1992-12-16  |  4.3 KB  |  107 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: Need help implementic data structures of generic objects
  5. Message-ID: <1992Dec16.132707.29252@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  9. References: <1992Dec11.233253.27540@informix.com> <1992Dec13.141400.5307@mole-end.matawan.nj.us> <1992Dec14.212143.15591@leland.Stanford.EDU>
  10. Date: Wed, 16 Dec 1992 13:27:07 GMT
  11. Lines: 94
  12.  
  13. In article <1992Dec14.212143.15591@leland.Stanford.EDU> kocks@leland.Stanford.EDU (Peter Kocks) writes:
  14. >My $0.02.  Use Obj-C.  I have just spent a fair amount of time comparing strong
  15. >vs weak type casting systems (sometimes called static vs. dynamic binding) and
  16. >have reached the following conclusions.  C++ is the optimum strong casting
  17. >language, 
  18.  
  19.     I dont think so. It doesnt have preconditions, and they are a
  20. crucial part of the type system. Eiffel does, so maybe it has
  21. a stronger type system than C++ in this area.
  22.  
  23.     It doesnt have class invariants either, which are more
  24. or less equivalent to preconditions if you construe the arguments
  25. to a function as an object.
  26.  
  27.     It does have exception specifications though, also
  28. somehow part of the type system.
  29.  
  30. >Smalltalk is the most popular weak casting system.  The ADVANTAGE
  31. >of C++ is that it is strong casting (which makes the prevention of bugs
  32. >considerably easier).  The ADVANTAGE of Smalltalk is that it is weak casting.
  33.  
  34.     Yes, precisely.
  35.  
  36. >The disadvantage of C++ is that when you want to do the more complex OOP
  37. >techniques, they often make the most sense in a weak casting language.  
  38.  
  39.     Is the issue really about 'more complex' techniques?
  40. Somehow I dont think this characterises the differences.
  41.  
  42. >C++ lets
  43. >you get around the need for weak casting by giving you such things as
  44. >templates.   Its not exactly the same, but it should enable you to implement
  45. >your design.  
  46.  
  47.     Not quite, I think where templates are used nicely you definitely
  48. DONT want the weak typing, if you did templates wouldnt work. So its
  49. the other way around, when you want a homogenous collection in the
  50. template-less language you cant have em, and you're forced to pay
  51. the price in terms of correctness and efficiency.
  52.  
  53. >It also means that C++ gets much more complex as you increase the
  54. >complexity of your OOP design.  The disadvantage of Smalltalk is that it can
  55. >be slow.  
  56.  
  57.     IMHO the principle 'theoretical' disadvantage what you
  58. mention below. That is the failure of the system to notify
  59. you in advance of potential errors.
  60.  
  61. >
  62. >Weak casting is a nice feature allowing you to send messages to objects without
  63. >knowing how (or if) the message can be implemented by the object.  It really
  64. >is great, but it makes for run-time errors which are bad (BUT not THAT bad). 
  65.  
  66.     I disagree vehmently :-)
  67.  
  68.     The *principal* advantage of C++ is that a whole class of
  69. errors cannot occur in running programs. Namely those caught by the type
  70. system.
  71.  
  72.     The problem in weakly typed systems is that there is no
  73. way to ever really KNOW that the program doesnt have bugs,
  74. I doubt even coverage analysis would be sufficient.
  75.  
  76.     In C++ you know.
  77.  
  78. >The solution, if you want a weakcasting system and you don't want to give
  79. >up C, is clearly Obj-C.  
  80.  
  81.     I heard a rumor that GNU provides C++ and Obj-C 
  82. togther in the one compiler?
  83.  
  84. >Unfortunately, we are stuck with C++ so the 
  85. >ultimate answer I believe is to forget about doing any kind of weak casting
  86. >design.  To do it in C++ is inviting disaster.  Smalltalk is not fast 
  87. >enough (well maybe it is) and it does not give you C code possiblities.  Obj-C
  88. >is the clear answer, but you'll be all alone.  
  89. >
  90. >I'm stuck with the same problem and I've decided to curse C++ and just
  91. >get on with using templates etc...
  92. >
  93.  
  94.     You are NOT stuck with 'C++', well not quite yet anyhow.
  95. The standard is still being 'created'. I for one find the
  96. dynamic loading ability of Obj-C interesting. I think this
  97. will be mandatory in the future, the old idea of compiling
  98. and linking a single standalone executable is just that,
  99. old--obsolete.
  100.  
  101.  
  102. -- 
  103. ;----------------------------------------------------------------------
  104.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  105.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  106. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  107.