home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #23 / NN_1992_23.iso / spool / vmsnet / internal / 1426 < prev    next >
Encoding:
Internet Message Format  |  1992-10-09  |  3.3 KB

  1. Xref: sparky vmsnet.internals:1426 vmsnet.misc:903 comp.lang.c:14736
  2. Path: sparky!uunet!destroyer!gatech!concert!ais.com!bruce
  3. From: bruce@ais.com (Bruce C. Wright)
  4. Newsgroups: vmsnet.internals,vmsnet.misc,comp.lang.c
  5. Subject: RE: C Language question
  6. Message-ID: <1992Oct9.110102.5773@ais.com>
  7. Date: 9 Oct 92 11:01:02 GMT
  8. References: <8543225@MVB.SAIC.COM>
  9. Organization: Applied Information Systems, Chapel Hill, NC
  10. Lines: 61
  11.  
  12. In article <8543225@MVB.SAIC.COM>, "Andy, Systems Manager" <UDAA055@ELM.CC.KCL.AC.UK> writes:
  13. > Nigel Arnot writes:
  14. >>Question: in C, if one declares char a[I][J], is there anything in the
  15. >>language standard that guarantees that &a[0][0] is the first of a set of
  16. >>I*J contiguous chars, and that a[i+1][0] is guaranteed to be the same
  17. >>storage location as a[i][J] ).
  18. >>
  19. > I suppose that it is conceivable for a compiler to use a mechanism for
  20. > indexing that allows the individual elements of an array to be scattered
  21. > in virtual memory. Assuming this is not the case then I think the
  22. > following explanation holds.
  23. > A single `dimensioned' array or vector, such as a[i], is contiguous in
  24. > memory in any language. (Obviously, otherwise indexing couldn't work).
  25.  
  26. This isn't quite true.  Most languages don't have a construct for
  27. non-connected storage, but it is by no means impossible.  PL/I for
  28. example has a mechanism for dealing with non-connected (non-contiguous)
  29. storage:
  30.  
  31.     non_connected:    procedure;
  32.     declare array (100, 100) fixed binary;
  33.     declare sub entry ((*) fixed binary);
  34.  
  35.         call sub (array (*, 1));
  36.         end non_connected;
  37.  
  38. Since elements are stored in row-major order in PL/I (as in just
  39. about every major language except Fortran), this fragment passes to
  40. the `sub' procedure a `slice' of the `array' which is formed from the
  41. first column of the array - or in other words, from every 101st element
  42. of the `array' as it is stored in memory.  The usual implementation is
  43. for the compiler to write a descriptor that describes the required `step'
  44. size for the array, and to pass that descriptor to the sub-procedure
  45. rather than the address of the array itself.  Because this is less
  46. efficient than indexing items in connected storage (because of the
  47. implied multiply that the optimizer can't reduce in strength since
  48. it doesn't know the multiplier at compile-time, unlike connected
  49. storage where it does know the element size and therefore the step
  50. size between elements), most implementations will pass the address
  51. of the array rather than the descriptor if the formal argument is
  52. declared to be `connected' or to have an explicit array size (the
  53. (*) in the declaration for `sub' says the array can have any size).
  54.  
  55. Anyway this is rather off the track.  C doesn't have a concept of
  56. `connected' versus `unconnected' storage of array items, and has
  57. the explicit definitions that the address of the array is equal to
  58. the address of array[0] and that successive elements of the array
  59. are stored in sequential addresses.  Since a multi-dimensional
  60. array in C is just an array of arrays, this implies that the entire
  61. object must be in connected storage.  I don't think that you could
  62. build a conforming compiler that didn't treat arrays the way Nigel
  63. describes.
  64.  
  65. If there is really a lot of interest in this topic maybe it should be
  66. moved to comp.lang.c or possibly vmsnet.misc rather than remain in
  67. vmsnet.internals, which is a VMS internals newsgroup ...
  68.  
  69. Bruce C. Wright
  70.