Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!psuvax1!psuvm!psuecl!c9h From: c9h@psuecl.bitnet Newsgroups: comp.sys.ibm.pc Subject: Re: Turbo C far pointers Message-ID: <63035@psuecl.bitnet> Date: 1 Nov 89 05:19:51 GMT References: <4037@cs.yale.edu> Followup-To: comp.sys.ibm.pc Organization: Engineering Computer Lab, Pennsylvania State University Lines: 35 In article <4037@cs.yale.edu>, spolsky-joel@CS.YALE.EDU (Joel Spolsky) writes: > In article hp0p+@andrew.cmu.edu (Hokkun Pang) writes: >>> 2) You really should use "ptr[i]" rather than "*(ptr+i)". It effectively >>> does the same thing, but it makes for much cleaner and much more >>> readable code. >> >>I read from a book that "ptr[i]" will be converted to "*(ptr+i)" by the >>compiler, so the "*(ptr+1)" is faster than "ptr[1]". Is that right? > > > That's ridiculous. *(A+1), A[1], and 1[A] all produce exactly the same > code. There is no reason to believe that the compiler prefers one over > the other, or that the compiler implements A[1] by first expanding > that to *(A+1). For all you know it does the opposite. > > And even if it did make a difference, it would be so small as to be > imperceivable even on the worlds slowest C compiler running on an > HP-41C. point is that "ptr[i]" makes more sense to the average person than "*(ptr+i)", and will, in fact, produce *exactly* the same code. And it most certainly WILL NOT produce the same code as "(*ptr)+i"! IF your compiler does this, then it is VERY non-standard. BTW: How long it takes the compiler to resolve an expression has very little to do with execution speed. Anyway, this has turned into an argument about semantics, and if anywhere, that should be constrained to comp.lang.c. - Charles Hannum | Klein bottle for sale ... | Live long and prosper. c9h@psuecl.psu.edu | inquire within. | cmh117@psuvm.psu.edu | | To life immortal!