home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / pascal / 6706 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  3.1 KB
  1. Path: sparky!uunet!utcsri!skule.ecf!torn!nott!cunews!revcan!software.mitel.com!kim!kim
  2. From: kim@Software.Mitel.COM (Kim Letkeman)
  3. Newsgroups: comp.lang.pascal
  4. Subject: Re: BP/TP OOP is missing something...
  5. Message-ID: <KIM.92Nov18082550@kim.Software.Mitel.COM>
  6. Date: 18 Nov 92 13:25:50 GMT
  7. References: <dmurdoch.282.722020256@mast.queensu.ca>
  8.     <1992Nov17.200839.342@news.clarkson.edu>
  9. Sender: kim@Software.Mitel.COM
  10. Organization: MITEL Public Switching, Kanata, Ontario, Canada
  11. Lines: 51
  12. In-reply-to: kooijman@sun.soe.clarkson.edu's message of 17 Nov 92 20:08:39 GMT
  13.  
  14. In article <1992Nov17.200839.342@news.clarkson.edu> kooijman@sun.soe.clarkson.edu (Harry Kooijman,Peyt314a,3808) writes:
  15.  
  16. | It is this couple of extra lines that make the difference between
  17. | using objects or not. With explicit calls to the
  18. | constructor/destructor I can write exactly the same code without
  19. | objects, and loose all the object overhead.
  20.  
  21. TP makes you determine the explicit timing of the construction and
  22. destruction of an object, but does not change the amount of overhead
  23. it takes to use an object. If automatic construction and destruction
  24. were implemented, the same level of overhead would still exist. But
  25. you wouldn't know about it because the code was executed for you.
  26.  
  27. In either mechanism, not using objects always eliminates object
  28. overhead. But, of course, the overhead of passing many parameters to
  29. many small functions in a library can easily outstrip the minor
  30. overhead associated with encapsulating the functionality into an
  31. object.
  32.  
  33. | What if you are adding a vector in a subroutine declaration list,
  34. | write the constructor, and use it, but forget to destruct it (an o
  35. | so easy and common bug): you start loosing heap. What if you forget
  36. | the constructor (worse!) ? If you have only a couple of vectors to
  37. | worry about you will probably not make this mistake. However if you
  38. | are dealing with 15 vectors and 15 matrices in one routine it
  39. | becomes a different matter. And that's why automatic construction
  40. | and destruction takes me further.
  41.  
  42. Forgetting to call constructors and destructors is a classic problem,
  43. but relatively easily debugged. All the complaining seems to be about
  44. local objects being constructed and destroyed as the object goes into
  45. and out of scope, which means that the code to construct and destroy
  46. the objects would typically be only a few lines apart anyway.
  47.  
  48. Manipulating large numbers of vectors and matrices in local scope has
  49. got to be pretty rare. And using them in a way that requires constant
  50. allocation and deallocation is so inefficient that I would expect
  51. steps to be taken to keep them in scope at all times (i.e. global) and
  52. just reuse the objects.
  53.  
  54. In other words, lets not worry too much about all these "one one
  55. hundredth of one percent" type problems. TPW is a very productive
  56. language because it is simple to use and yet very powerful. Making it
  57. into yet another C++ just defeates the purpose of having two separate
  58. languages.
  59.  
  60. I'd hate to only have a choice between one incredibly complex language
  61. and another slightly different looking but equally comlpex language.
  62.  
  63. --
  64. Kim Letkeman    kim@Software.Mitel.COM
  65.