home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / mac / oop / macapp3 / 655 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.7 KB  |  55 lines
  1. Path: sparky!uunet!pageworks.com!world!eff!sol.ctr.columbia.edu!spool.mu.edu!agate!stanford.edu!apple!applelink.apple.com
  2. From: ALANDAIL@AppleLink.Apple.COM (Personal Software, Alan Dail,PRT)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Re2: Re2: C++ (was re: bedrock
  5. Message-ID: <728241041.8321163@AppleLink.Apple.COM>
  6. Date: 28 Jan 93 16:43:00 GMT
  7. Sender: daemon@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 44
  10.  
  11. Mark,
  12.  
  13. >>I agree that stack-based objects are usefull. However, I don't think they are
  14. >>quite the same thing as a class and could be restricted to structs.
  15.  
  16. >Heh, never tried resource acquisition? If MacApp had real exception handling
  17. >you'd see a LOT of stack-based classes for that purpose.
  18.  
  19. I think you missed my point about stack based objects.  (Perhapse "restricting
  20. class based objects to structs" went to far.  I was suggesting that there is a
  21. difference between a new "type" and a new "class".  (I am defining a type as
  22. something that is designed to have no virtual methods.)  In general, objects
  23. that are designed to be stack based are really new types (i.e. CStr255), which
  24. struct handles nicely.  A class, on the other hand, should have most, if not
  25. all, of it's non private methods virtual.  However, in c++, EVERYTHING defaults
  26. to nonvirtual.  This give a bias for methods to be nonvirtual until a reason
  27. (performance) is discovered for them to be virtual.  The bias should be for
  28. methods to be virtual.  Even better would be to have this issue resolved by the
  29. linker like Object Pascal does, or the environment.
  30.  
  31. >Or use an intelligent DevEnv like Component Workshop.
  32. I thought that Component Workshop also requires you to specify a method to be
  33. virtual.  Also, Component Workshop isn't really C++.  What do you if you want
  34. to port any of your Component Workshop code to Window or Unix, or Pink?  Not to
  35. put down component workshop, but one of the attactions C++ has is that you know
  36. that you can find at least one C++ compiler on pretty much any system you want
  37. to port any of your code to.
  38.  
  39. >>I don't think any of these changes would this would impact the power of C++,
  40. >>but would make it less error prone and easier to learn.
  41. >How do stack-based objects make C++ harder to learn?
  42.  
  43. The fact that they cause nonvirtual to be the default for class makes the
  44. language more error prone.  Also, I was referring to all of the possibble
  45. language changes I mentioned when I made this statement.
  46.  
  47. Alan
  48.  
  49. PS  It's too late to complain about these problems with C++ anyway.  Changing
  50. them would break too much code.  I just hope the designer of the next language
  51. that gains wide spread acceptance realises that programmer productivity can be
  52. improved more by having the compiler catch mistakes for you than by always
  53. striving to reduce the number of characters you have to type.
  54.  
  55.