Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!abcfd20.larc.nasa.gov!ipsun.larc.nasa.gov!jcburt From: jcburt@ipsun.larc.nasa.gov (John Burton) Newsgroups: comp.society.futures Subject: Re: C's sins of commission (was: (pssst...fortran?)) Message-ID: <1990Sep21.222152.22479@abcfd20.larc.nasa.gov> Date: 21 Sep 90 22:21:52 GMT References: <1990Sep21.193403.20381@abcfd20.larc.nasa.gov> <63751@lanl.gov> Sender: news@abcfd20.larc.nasa.gov (USENET File Owner) Organization: NASA Langley Research Center, Hampton, VA USA Lines: 101 In article <63751@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <1990Sep21.193403.20381@abcfd20.larc.nasa.gov>, by jcburt@ipsun.larc.nasa.gov (John Burton): >> In article <63722@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >> [...] >>>Hear, Hear!! I like a programming language to allow me to say what I >>>mean - not to have to convert my algorithm into something cryptic. >>>However, C forces me to encrypt my programs - I can't use arrays, I >>>have to encrypt them as pointers; I can't use dynamic memory, I have >>>to encrypt them as pointers; I can't use mapping (run-time equivalence), >>> [...] >>> >> Excuse me? are you REALLY saying you CAN'T use arrays in C without >> resorting to pointers??? I'm confused. Does this mean that I can't >> use the statement >> a[i][j] = 123; > >Syntactic suger. Try sending the 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. > >What I want is an array that _stays_ an array when I pass it around. >Arrays that have to be locally declared or global are practically >useless for programs which do any serious array manipulation. For >them, arrays in C are not anthing but another name for pointer. By the same token, in reality ALL variables in C, FORTRAN, Pascal, etc are simply pointers. They do not contain a value themselves, they point to a memory location that contains the value. Also in reality an array is just a sequence of memory locations. How you access those locations is a matter of preference. Any way you do it you ultimately reference a memory location (or register) and obtain the value there. Explicitly defined pointers simply are indentifiers pointing to a memory location which contain the address of another memory location. One point that intrigues me is _how_ you plan to pass your array around so that it _stays_ an array without using pointers. The primary choices for paramter passing seem to be either make a copy of the data within the subroutine (pass by value or copy-in) or tell the routine _where_ the data is stored (pass by reference), i.e. you either pass the value or a pointer to a value. My interpretation of what you say is that you want to eliminate passing the pointer (pass by reference). This does have the advantage of not allowing anyone else access to the copy of the array as the subroutine works on it, but it has the disadvantage of requiring copies to be made of the array. I'm not convinced that making a copy of a 4 meg array can be done faster than passing a pointer. > >> Can't use dynamic memory without using pointers? Again, I assume that's >> not *really* what you mean...I can send you code to create 2,3,... >> whatever Dimensioned array you want from the heap (using malloc & >> calloc) that can be used in any situation where you use a statically >> declared one (I have yet to find a situation where it doesn't work) >> using exactly the same syntax. It works on all the compilers mentioned >> above using the ANSI standard mode. I use this routine regularly in >> the image processing work I do...the only problem I've run into is >> running out of memory for 2-D arrays larger than 1024x1024 of type >> float. > >Ok. Now give me code in which those declarations resemble static >array declarations in any significant way. The declaration of a >dynamic object should be _identical_ to the declaration of a static >object of the same type (with the possible exception of place-holders Why should it be identical? what purpose would that serve save hiding the fact that the machine is doing two different operation (allocating space at compile time vs. allocating space at run time). > >Once you've failed to do that. Then you can tell me how the compiler >knows that the pointers (hidden under your clever declarations) are to >dynamic objects and are not aliased to _any_ other pointers. In order to >get any kind of efficiency, the compiler must be able to detect aliasing >so that it can optimize non-aliased references. However, as far as the >compiler knows, the result of a malloc() or calloc() call is just any old >pointer, could be aliased to anything. > >No, the techniques you are advocating (which I've seen before and >dismissed for the same reasons) merely hide the facts. This is >doubly cryptic - you are pretending to be arrays when you're really >using pointers, and you are using pointers because the language doesn't >really have arrays. I still prefer to tell the compiler straight out >what it is I want to do. As far as a machine goes, there is no such thing as array. So whats the difference between *me* "hiding the facts" and the compiler "hiding the facts". Personally I prefer to know whats going on as opposed to handing the job to the compiler and hopes it does what i think it does. If I want to use pointers as opposed to arrays, or vice versa, that should be my choice, NOT a restriction of the language. This whole discussion boils down to a difference of opinion. I hold that a programmer should be allowed the freedom to create programs in whatever way he/she chooses and be provided the tools to do the job. What you're proposing significantly limits this freedom of choice. What advantages does this limiting provide? By your own words, None...both methods (supposedly) can be used to create the same end product. John Burton "Save me from those who seek to save me from myself"