Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!samsung!usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!kullmar!pkmab!ske From: ske@pkmab.se (Kristoffer Eriksson) Newsgroups: comp.lang.misc Subject: Re: Pointers as 3-tuples (Re: JLG's flogging of horses) Message-ID: <3308@pkmab.se> Date: 13 Apr 90 02:04:54 GMT References: <14327@lambda.UUCP> Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden Lines: 93 In article <14327@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes: >You have 'demonstrated' no such thing. You have proposed an implementation >which would _make_ my first statement false. You have asserted (perhaps >correctly) that the new C standard actually supports your interpretation. >However, you have _NOT_ demonstrated that pointers which obey bounds are >more general that arrays (they aren't). Pointers can still be assigned to, and thus point to or into different arrays or structures at different times. Arrays can't. Just because you have bounds in the pointers, doesn't mean that a particular pointer variable has to contain the same bounds at every time. > You have _NOT_ demonstrated that pointers _should_ obey bounds. Of course they "should". At least the C standard explicitely leaves room for bounds checking. You are not required not to check bounds. Thus, you may choose freely whether to do it or not. If you like bounds checking in general, naturally you want it on pointers too. >In fact, what you are recommending is a constraint on pointers which >removes one of the _only_ features that I thought pointers were useful >for. I don't know what you are thinking of here. If it is possible for pointer variables to point at different objects at different times, and there is a mechanism for obtaining pointers with smaller bounds from pointers with larger bounds, for instance some kind of casting, I can't imagine what more you could posible desire. > I already had a pretty low opinion about the value of pointers >and you are busy destroying what respect I had left. If it is your >intent to make pointers seem _less_ useful than they might be, you >are succeeding. It seems to me that here, you are fooling yourself somehow. Either you had unrealistic views of how pointer could be used, to start with (but I haven't seen any other evidence for that), or you are somehow misinterpreting the effects of putting bounds into the pointers. >main(){ > int A[10][20]; > ... > sub1(A); > ... >} > sub1(pa) >Actually, of course, C has no way of doing this. The procedure can't >find out the dimensions of the argument. And even if I were to pass >the values 10 and 20 as separate arguments, the C declaration rules >would not permit me to declare 'pa' as "int pa[bnd1][bnd2]". Doesn't GNU C allow that kind of variable declarations? Ok, they're not allowed by the C standard, but there's no inherent difficulty in adding them. >No, 'pa' is isomorphic to a one-dimensional array with bound 10*20==200. >You can move 'pa' around linearly by adding and subtracting to it, but >you can _never_ double subscript it. As has been pointed out, it's never been a problem to double subscript function arguments, if you declare them like arrays with constant sizes, and expanding the language to allow variable sizes wouldn't change the pointer concept of C in the least, thus this particular point is not inherent to pointers. Maybe we should try not to confuse the general usefulness of pointers and what particular features for using pointers are included in the C-standard at one particular moment in time. Also, when you for instance say that C should be changed to include real arrays rather than bounds-checking pointers, don't you rather mean _non-aliased_ and constant references (whether arrays or pointers acting as arrays) ? Just because aliased arrays are disallowed in Fortran, does that make non-aliasing an inherent feature of arrays? Isn't this, again, confusing arrays with rules that apply to arrays in one (or several) particular language? Why don't you simply say that you'd like C to include non-aliased arrays, to be able to optimize the particular kind of applications that you are involved in, and leave it at that, rather than saying that pointers are bad and C is bad and Fortran or anything else is better. Can't we just agree that C and Fortran have radically different historical backgrounds? I'd say that on many points you are technically right in what you say, except, sometimes, about C details, but your _perspective_ is what upsets most people. The views about what is important in a particular language, what is useful, what should be required by every language regardless of background, and so on. -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske