home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #23 / NN_1992_23.iso / spool / vmsnet / internal / 1416 < prev    next >
Encoding:
Text File  |  1992-10-08  |  3.0 KB  |  91 lines
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!usc!news.service.uci.edu!unogate!mvb.saic.com!macro32
  2. From: "Andy, Systems Manager" <UDAA055@ELM.CC.KCL.AC.UK>
  3. Newsgroups: vmsnet.internals
  4. Subject: RE: C Language question
  5. Message-ID: <8543225@MVB.SAIC.COM>
  6. Date: Thu, 8 Oct 92  12:39 BST
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 80
  10.  
  11. Nigel Arnot writes:
  12.  
  13. >Question: in C, if one declares char a[I][J], is there anything in the
  14. >language standard that guarantees that &a[0][0] is the first of a set of
  15. >I*J contiguous chars, and that a[i+1][0] is guaranteed to be the same
  16. >storage location as a[i][J] ).
  17. >
  18.  
  19. I suppose that it is conceivable for a compiler to use a mechanism for indexing
  20. that allows the individual elements of an array to be scattered in virtual
  21. memory. Assuming this is not the case then I think the following explanation
  22. holds.
  23.  
  24. A single `dimensioned' array or vector, such as a[i], is contiguous in memory
  25. in any language. (Obviously, otherwise indexing couldn't work).
  26.  
  27. So:
  28.  
  29.    int a[i]
  30.  
  31. simply states that a is an array of contiguous ints (i of them).
  32.  
  33. Now if we consider a two dimensional array, such as a[i][j], as a vector where
  34. each element is itself a vector (as I believe the C standard does, although
  35. maybe only implictly rather than explicitly), then clearly the same rules apply.
  36.  
  37. So:
  38.  
  39.    int a[i][j]
  40.  
  41. could be considered as:
  42.  
  43.    typedef int vector[i];
  44.    vector  a[j];
  45.  
  46. where a is still a vector, but each element is a contiguous array of integers.
  47.  
  48. Clearly all the elements of a must therefore be contiguous!
  49.  
  50. This tends to be borne out by most C compilers; I dont think I've ever met one
  51. that allocates the space non contiguously. That's not proof of course, merely
  52. the implementor's interpretation of the standard but, I think, an accurate one.
  53.  
  54.  
  55. >A friend asserts that it is, and says his experience on several systems
  56. >'proves' this. My belief is that there is nothing that says this will
  57. >always be the case, and that the only constraint is that every valid pointer
  58. >a[i] will point to J chars. Which of us is right?
  59.  
  60.  
  61. C is certainly confusing in this area in that, although pointers and arrays are
  62. often interchangeable, what you are ACTUALLY allowed to do and how the storage
  63. is allocated, depends on how you originally define the arrays.
  64.  
  65. For example:
  66.  
  67.    char c[10]="123456789";
  68.    char *c = "123456789";
  69.  
  70. Initially, the program sees a similar data structure, but the programmer has
  71. different constraints on each. For example:
  72.  
  73.   1.   c = &x  is invalid for the first but ok for the second.
  74.  
  75.   2.   The first declaration allocates storage in writeable memory and then
  76.        initializes it.  The second however sets the data up in read-only
  77.        memory and sets c to point at it.
  78.  
  79. Nigel's assertion is correct only if the array has been declared slightly
  80. differently:
  81.  
  82.    typedef char string[j]
  83.    string *a[i]
  84.  
  85. Where a is defined as an array of pointers to string.  Although the syntax is
  86. similar, the meaning is somewhat different.
  87.  
  88.  
  89. Andy Harper
  90. Kings College London, England
  91.