home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / pascal / 8050 < prev    next >
Encoding:
Text File  |  1993-01-11  |  3.2 KB  |  68 lines
  1. Newsgroups: comp.lang.pascal
  2. Path: sparky!uunet!cs.utexas.edu!torn!utcsri!newsflash.concordia.ca!sifon!thunder.mcrcim.mcgill.edu!poly-vlsi!music.mus.polymtl.ca
  3. From: Steph <CT80@music.mus.polymtl.ca>
  4. Subject: Re: TVision : BUG in my head or in TV?
  5. Message-ID: <07JAN93.20698633.0034@music.mus.polymtl.ca>
  6. Lines: 56
  7. Sender: usenet@music.mus.polymtl.ca
  8. Organization: Ecole Polytechnique de Montreal
  9. References: <30DEC92.02825818.0033@music.mus.polymtl.ca> <dmurdoch.262.725736007@mast.queensu.ca> <30DEC92.14039571.0035@music.mus.polymtl.ca> <1993Jan4.203255.2366@ncsu.edu>
  10. Date: Fri, 8 Jan 1993 00:09:55 GMT
  11.  
  12. >
  13. >This harkens back to a rather ANCIENT debate as to whether a program
  14. >or operating system should PRE-initialize the memory image to ZEROs
  15. >or leave whatever garbage values were in memory at the instance of
  16. >"loading."   Bugs due to UNinitialized memory variables SET TO ZERO or
  17. >NIL (for pointers) are easier to diagnose and are more CONSISTANT in
  18. >behavior than are  UNinitialized memory variable with RANDOM garbage
  19. >values that "work" sometimes and don't "work" other times.
  20. >
  21. >NOTE: MASM and TASM have directives for allocating either memory INITIALIZED
  22. >to $00 or to be left in garbage state.
  23. >
  24. >Therefore, Borland made a design decision.  Contrary to Duncans assertion,
  25. >it is not a "mistake."  It is a design decision.  Though I do not know
  26. >the intimate details of Protected Mode programming and Windows programming,
  27. >I do know that there is a significant difference from DOS programming
  28. >and MEMORY MANAGEMENT.  Therefore, without first hearing a pro- or con-
  29. >debate on the merits of memory zeroing--or not--in a particular situation,
  30. >I'd hesitate to criticize TObject memory zeroing.
  31. >
  32. >As far as Steph needing to learn to "build" around it (memory zeroing in
  33. >DOS TV), I'd put forth that I use it to *advantage* and am quite glad
  34. >it is done.  :^)
  35. >
  36. >Of course, anyone who bought BP7 also got TV source code and therefore
  37. >can easily comment out the couple of lines that do the memory
  38. >zeroing...and find out whether your code generation life is happier and
  39. >easier!  :^)
  40. >
  41. >Steve
  42. >---
  43. >+------------------------------------------------------------------+
  44. >|     In person:  Steve Modena     AB4EL                           |
  45. >|     On phone:   (919) 515-5328                                   |
  46. >|     At e-mail:  nmodena@unity.ncsu.edu                           |
  47. >|                 samodena@csemail.cropsci.ncsu.edu                |
  48. >|                 [ either email address is read each day ]        |
  49. >|     By snail:   Crop Sci Dept, Box 7620, NCSU, Raleigh, NC 27695 |
  50. >+------------------------------------------------------------------+
  51. >         Lighten UP!  It's just a computer doing that to you.    (c)
  52. >OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
  53. >
  54. >.
  55. >.
  56.  
  57. I wouldn't use it.  Even though TV might zero data fields, Turbo
  58. Pascal itself doesn't, so in _my_ book it's bad practice to use this
  59. feature, especially if not all versions do it, for instance.
  60.  
  61. 'sides, they always thought me that un-initialized variables are a
  62. bad programming practice.  I know that if I were to read someone
  63. else's code that used hidden features of TVision, I'd quickly get
  64. lost.  I'll stick to doing InitVar := 0, thank you.  :)
  65.  
  66. Steph.
  67.  
  68.