Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!carroll
From: carroll@m.cs.uiuc.edu
Newsgroups: comp.lang.misc
Subject: Re: Anyone want to design a languag
Message-ID: <5200044@m.cs.uiuc.edu>
Date: 24 Feb 90 10:40:03 GMT
References: <14248@lambda.UUCP>
Lines: 45
Nf-ID: #R:lambda.UUCP:14248:m.cs.uiuc.edu:5200044:000:2599
Nf-From: m.cs.uiuc.edu!carroll    Feb 23 10:08:00 1990


>/* Written  5:34 pm  Feb 22, 1990 by jlg@lambda.UUCP in m.cs.uiuc.edu:comp.lang.misc */
>/* ---------- "Re: Anyone want to design a languag" ---------- */
>From article <18172@megaron.cs.arizona.edu>, by mike@cs.arizona.edu (Mike Coffin):
>> [...]
>> A correction for those readers not familiar with C: the above is not
>> true.  Arrays and pointers are different beasts.  The confusion arises
>> because array names are *converted* to pointers when passed as
>> parameters and because the [] operator can be used on both.
>
>A correction for those readers not familiar with C: the above is not
>true.  Arrays are pretty useless unless you can pass them around as
>procedure arguments.  C converts all arrays to pointers when passing
>them to procedures.  AND: YOU _CAN'T_ CONVERT THEM BACK ONCE YOU'RE
>THERE!!!!!  They are not treated as arrays anywhere except the scope
>in which they were declared - and CAN'T be treated as arrays anywhere
>except their home scope.
>
>To make an analogy, it's as if, once an integer was converted to real,
>it could _never_ be converted back!  And normal usage of integers
>_forces_ you to convert them to real on frequent occasions.  So that,
>in effect, you really _DON'T_ have integers.  Fortunately, even C
>doesn't really do this to integers.  But is DOES do the corresponding
>thing to arrays.
>
>J. Giles
>/* End of text from m.cs.uiuc.edu:comp.lang.misc */
{Chris,Henry,Doug} correct me if I'm wrong, but I've always viewed array
names simply as _constant_ pointers. IMHO, all of the differences between
pointers and arrays can be understood by this model (and, of course, it
does correspond to the underlying implementation). So, when you pass an
array name to a function, it get converted to a pointer just like the
constant 4 gets converted to an integer variable, and you can't ever convert
it back to a constant. So, your analogy is flawed. It also fails because
it relies on the underlying assumption of the reader that floats are slower
than int's, and require different operators/declarations, when such things
do not happen with the array/pointer "conversions". The only "conversion"
is that the value of the array name is put into a variable.

Alan M. Carroll                "Like the north wind whistling down the sky,
carroll@cs.uiuc.edu             I've got a song, I've got a song.
Conversation Builder:           I carry it with me and I sing it loud
+ Tomorrow's Tools Today +      If it gets me nowhere, I'll go there proud"
Epoch Development Team          
CS Grad / U of Ill @ Urbana    ...{ucbvax,pur-ee,convex}!cs.uiuc.edu!carroll