jerbil@nntp-server.caltech.edu (Joseph R. Beckenbach) (09/22/90)
Apparently I am missing a good many things in this thread. It seems that there are several assumptions which never appeared in earlier postings, and which underlie the argument so far. Time to ask participants to regroup, so I can be sure I'm reading articles with semantic content? jlg@lanl.gov (Jim Giles) writes: >Try sending [an] array to a subroutine as a parameter. >Then you'll find out what the array _really_ is. Try referencing the >array in the subroutine with the above statement - lots of luck. I'm confused. Please specify language and computational model. And intended properties of 'array', if possible: I'm reading 'array' as a collection of entities of identical type whose relationships to each other corresponds to a (finite-length) arithmetic sequence, which sequence elements can be considered 'indices' or 'addresses'. >What I want is an array that _stays_ an array when I pass it around. What properties of an 'array' are being violated when the 'array' is "passed around"? Again, please focus. >[a]rrays in C are not anthing but another name for pointer. Arrays in C _are_ arrays. 'char buffer[800]' seems to satisfy my expectation that I wish an array of 800 'chars', to be later referenced using the name 'buffer'. References to (and into) arrays in C _are_ pointers. If a different model is wished on a C platform, it can be hidden within a data-type using 'typedef' and functions to manipulate that data-type. As Mr. Giles implies, those who do not keep straight the difference will find subtle errors -- or rather, will take a long time finding subtle errors. I can testify to that first-, second-, and third-hand. As for most of the thread so far, I cannot understand what question is under consideration, so I refrain from comment. Joseph Beckenbach
jlg@lanl.gov (Jim Giles) (09/25/90)
From article <1990Sep21.224554.23257@nntp-server.caltech.edu>, by jerbil@nntp-server.caltech.edu (Joseph R. Beckenbach): > [...] > jlg@lanl.gov (Jim Giles) writes: >>Try sending [an] array to a subroutine as a parameter. >>Then you'll find out what the array _really_ is. Try referencing the >>array in the subroutine with the above statement - lots of luck. > > I'm confused. Please specify language and computational model. > And intended properties of 'array', if possible: I'm reading 'array' > as a collection of entities of identical type whose relationships to > each other corresponds to a (finite-length) arithmetic sequence, which > sequence elements can be considered 'indices' or 'addresses'. Well, close. An array is a mapping from one or more orthogonal finite length sequences to elements of some underlying type. The nature and internal implementations of this mapping is _usually_ irrelevant to the programmer. All he wants is some assurance that it will be efficient enough for his application. Note, there is nothing in this definition which requires "addresses" (at least, not the absolute internal kind - you _could_ regard a collection of indices selected from the various orthogonal sets as a sort of multidimensional address). Nothing in this definition requires the elements of the underlying type to be all the same size (although, if they are, the user would expect the compiler to optimize accordingly). One final thing: different objects of type "array" should be regarded as disjoint (and, indeed, be required to be disjoint). If aliasing is desired, additional explicit requests from the programmer should be required. This helps both the user in debugging his code as well as the compiler in producing efficient code. Turning an array into a pointer (like C does) loses the properties above. The dimensionality and extent information can only be recovered by peculiar declarations or marcos or both - none of which really resemble the original declaration of the object. The 'no-alias' property of the above definition can _never_ be recovered in C. > [...] > If a different model is wished on a C platform, it can be hidden within > a data-type using 'typedef' and functions to manipulate that data-type. Unless the functions for manipulation are "inline", I will have lost much efficieny by this arrangement. Even applications which can tolerate inefficient code to some extent would probably consider the transformation of array indexing into a procedure call intolerable. Besides, C typedefs aren't powerful enough. All objects with the same typedef must be the same size - but we all know that array sizes vary. Matrix multiply must be the same procedure on two 4x4 arrays as on a 2x8 times an 8x2. The usually C method of 'solving' this problem is to do things like matrix multiply entirtely with pointers and not even _pretend_ that the language can handle it with arrays. The issue is not "can it be done in C with pointers", or even "can pointers be hidden by clever declarations", but, "are pointers even desireable on a programmer-level at all?" I'm not sure they are. Making pointers explicitly visable implies that there's something important - to the programmer himself - about addresses. The very existence of, say, a loader, or a symbolic debugger, seems to argue that programmers usually _don't_ want to be bothered with the actual addresses - just so he can get to his data. Well, if the address isn't important to the programmer, then why does the programming language need a data type to represent it? J. Giles