home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!stanford.edu!agate!usenet.ins.cwru.edu!ukma!darwin.sura.net!zaphod.mps.ohio-state.edu!usc!news.service.uci.edu!unogate!mvb.saic.com!macro32
- From: REGI's <NUNEZ@esevvx.cica.es>
- Newsgroups: vmsnet.internals
- Subject: (None)
- Message-ID: <01GPZGKLQOYO0001ZZ@esevvx.cica.es>
- Date: Thu, 15 Oct 1992 16:50:00 UTC+0100
- Organization: Macro32<==>Vmsnet.Internals Gateway
- X-Gateway-Source-Info: Mailing List
- Lines: 99
-
- >X-Envelope-to: MACRO32@WKUVX1.bitnet
- >X-VMS-To: IN::"MACRO32@WKUVX1.BITNET"
-
- 1
- 12-OCT-1992 20:04:35.45
- 1 00:00:00.00
- 13-OCT-1992 20:04:35.45
- @UKCC.uky.edu:MacroMan@WKUVX1.BITNET
- gutier@SEVAXU.CICA.ES
-
- Received: from UKCC.uky.edu by ESEVVX.CICA.ES ; 9-OCT-1992 20:04:32.46
- Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
- with BSMTP id 4897; Fri, 09 Oct 92 13:39:07 EDT
- Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 6915;
- Fri, 09 Oct 92 13:39:06 EDT
- Errors-To: MacroMan@WKUVX1.BITNET
- X-ListName: "VMS Internals, MACRO, and BLISS Discussions"
- <MACRO32@WKUVX1.BITNET>
- Received: from CUNYVM.BITNET (MAILER) by WKUVX1 (MX V3.1C) with BSMTP; Fri, 09
- Oct 1992 12:32:27 CDT
- Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 8368; Fri,
- 09 Oct 92 13:23:23 EDT
- Received: from MVB.SAIC.COM by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP;
- Fri, 09 Oct 92 13:23:20 EDT
- Xref: unogate vmsnet.internals:1419 vmsnet.misc:1011 comp.lang.c:21899
- From: <bruce@ais.com>
- Reply-To: MACRO32@WKUVX1.BITNET
- X-Newsgroups: vmsnet.internals,vmsnet.misc,comp.lang.c
- Subject: RE: C Language question
- Message-ID: <1992Oct9.110102.5773@ais.com>
- Date: 9 Oct 92 11:01:02 GMT
- References: <8543225@MVB.SAIC.COM>
- Organization: Applied Information Systems, Chapel Hill, NC
- Lines: 61
- To: MACRO32@WKUVX1.BITNET
- X-Gateway-Source-Info: USENET
-
- In article <8543225@MVB.SAIC.COM>, "Andy, Systems Manager"
- <UDAA055@ELM.CC.KCL.AC.UK> writes:
- > Nigel Arnot writes:
- >
- >>Question: in C, if one declares char a[I][J], is there anything in the
- >>language standard that guarantees that &a[0][0] is the first of a set of
- >>I*J contiguous chars, and that a[i+1][0] is guaranteed to be the same
- >>storage location as a[i][J] ).
- >>
- >
- > I suppose that it is conceivable for a compiler to use a mechanism for
- > indexing that allows the individual elements of an array to be scattered
- > in virtual memory. Assuming this is not the case then I think the
- > following explanation holds.
- >
- > A single `dimensioned' array or vector, such as a[i], is contiguous in
- > memory in any language. (Obviously, otherwise indexing couldn't work).
-
- This isn't quite true. Most languages don't have a construct for
- non-connected storage, but it is by no means impossible. PL/I for
- example has a mechanism for dealing with non-connected (non-contiguous)
- storage:
-
- non_connected: procedure;
- declare array (100, 100) fixed binary;
- declare sub entry ((*) fixed binary);
-
- call sub (array (*, 1));
- end non_connected;
-
- Since elements are stored in row-major order in PL/I (as in just
- about every major language except Fortran), this fragment passes to
- the `sub' procedure a `slice' of the `array' which is formed from the
- first column of the array - or in other words, from every 101st element
- of the `array' as it is stored in memory. The usual implementation is
- for the compiler to write a descriptor that describes the required `step'
- size for the array, and to pass that descriptor to the sub-procedure
- rather than the address of the array itself. Because this is less
- efficient than indexing items in connected storage (because of the
- implied multiply that the optimizer can't reduce in strength since
- it doesn't know the multiplier at compile-time, unlike connected
- storage where it does know the element size and therefore the step
- size between elements), most implementations will pass the address
- of the array rather than the descriptor if the formal argument is
- declared to be `connected' or to have an explicit array size (the
- (*) in the declaration for `sub' says the array can have any size).
-
- Anyway this is rather off the track. C doesn't have a concept of
- `connected' versus `unconnected' storage of array items, and has
- the explicit definitions that the address of the array is equal to
- the address of array[0] and that successive elements of the array
- are stored in sequential addresses. Since a multi-dimensional
- array in C is just an array of arrays, this implies that the entire
- object must be in connected storage. I don't think that you could
- build a conforming compiler that didn't treat arrays the way Nigel
- describes.
-
- If there is really a lot of interest in this topic maybe it should be
- moved to comp.lang.c or possibly vmsnet.misc rather than remain in
- vmsnet.internals, which is a VMS internals newsgroup ...
-
- Bruce C. Wright
-