home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / misc / 3536 < prev    next >
Encoding:
Text File  |  1992-11-08  |  2.1 KB  |  42 lines
  1. Newsgroups: comp.lang.misc
  2. Path: sparky!uunet!pmafire!mica.inel.gov!ux1!news.byu.edu!hamblin.math.byu.edu!sol.ctr.columbia.edu!caen!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
  3. From: jlg@cochiti.lanl.gov (J. Giles)
  4. Subject: Re: Pointers
  5. Message-ID: <1992Nov6.190610.5786@newshost.lanl.gov>
  6. Sender: news@newshost.lanl.gov
  7. Organization: Los Alamos National Laboratory
  8. References: <1992Nov5.014143.15635@newshost.lanl.gov> <1992Nov5.051745.7369@linus.mitre.org> <1992Nov5.184831.16328@newshost.lanl.gov> <1de603INN5qv@early-bird.think.com>
  9. Date: Fri, 6 Nov 1992 19:06:10 GMT
  10. Lines: 30
  11.  
  12. In article <1de603INN5qv@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
  13. |> [...]
  14. |> And it's possible to have aliasing without pointer variables.  Fortran has
  15. |> this problem because parameters are passed by reference -- their solution
  16. |> was simply to legislate that programs are not permitted to pass array
  17. |> parameters (or is it all parameters) in such a fashion that such aliases
  18. |> would occur.  It's not possible to detect this statically in the general
  19. |> case.
  20.  
  21. Quite true.  Fortran commits the same error as C, but in the reverse
  22. direction.  What I want is for the language to allow aliasing, allow
  23. the user to explicitly state whether things are *really* aliased or
  24. not (with *NOT ALIASED* and the default).  The fact that the non-alias
  25. legislation is not statically determinable is not relevant to me: I'm
  26. perfectly willing to take that responsibility for my use of the code.
  27.  
  28. The point is that aliasing is an *inherent* part of what pointers do,
  29. it is merely a rarely used possibility with arrays (one which I'm
  30. perfectly willing to do completely without).  The distinction is 
  31. therefore naturally divided - if you *call* something an array, the
  32. compiler assumes it's not aliased to anything; if you *call* something
  33. a pointer the compiler assumes that it might be aliased.  In short, 
  34. part of the distinction you make between pointers and arrays is the
  35. explicit control over aliasing I mentioned in the preceding paragraph.
  36.  
  37. Thus, if you coerce one to the other in every procedure call, you have
  38. lost a useful distinction.  It's a bad idea to coerce arrays to pointers.
  39.  
  40. -- 
  41. J. Giles
  42.