home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / misc / 3694 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  1.5 KB
  1. Path: sparky!uunet!utcsri!neat.cs.toronto.edu!tlai
  2. Newsgroups: comp.lang.misc
  3. From: tlai@cs.toronto.edu (Tony Wen Hsun Lai)
  4. Subject: Re: Accessing the hardware directly (Was: Pointers)
  5. Message-ID: <92Nov15.195430est.47880@neat.cs.toronto.edu>
  6. Organization: Department of Computer Science, University of Toronto
  7. References: <721626972@sheol.UUCP> <BxpsHo.MID@mentor.cc.purdue.edu> <mwm.2n3n@contessa.palo-alto.ca.us> <BxrK6x.A04@mentor.cc.purdue.edu>
  8. Date: 16 Nov 92 00:54:41 GMT
  9. Lines: 19
  10.  
  11. In article <BxrK6x.A04@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  12. [stuff deleted]
  13. >I do not see how any system of references will enable writing
  14. >
  15. >    *fill(*descriptor)
  16. >
  17. >any faster.  Nor do I trust compiler writers (or government bureaucrats.)
  18. >And if the lack of pointers in the languages causes hardware to elide pointers
  19. >in favor of something clumsy like call_by_name, searching the name file, we
  20. >all lose.  I have also pointed out that I want to use this in cases in which
  21. >the calling routine does not even know the name.  True, you could read the
  22. >name, but is that any easier than reading the address?
  23.  
  24. I guess you don't like pass by reference?  Pass by reference is almost
  25. inevitably implemented using pointers, but doesn't involve _explicit_
  26. pointers set up by the programmer.  You may not need or appreciate
  27. abstractions for your programming, but if you look at the evolution of
  28. language design, abstractions are important for designing and writing very
  29. large, maintainable programs.
  30.