Xref: utzoo comp.sys.ibm.pc:37423 alt.msdos.programmer:629 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!lotus!esegue!johnl From: johnl@esegue.segue.boston.ma.us (John R. Levine) Newsgroups: comp.sys.ibm.pc,alt.msdos.programmer Subject: Re: Turbo C far pointers Message-ID: <1989Nov1.203207.8289@esegue.segue.boston.ma.us> Date: 1 Nov 89 20:32:07 GMT References: <150@norsat.UUCP> Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine) Organization: Segue Software, Cambridge MA Lines: 28 In article <150@norsat.UUCP> dbin@norsat.UUCP (Dave Binette) writes: >In article hp0p+@andrew.cmu.edu (Hokkun Pang) writes: >>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? >... >Some CPU's handle array indexing more efficiently than pointers so in either >case your [sic] kind of at the mercy of those who ported the compiler to your >machine. Sheesh. The two expressions are defined by the language to mean exactly the same thing. Anywhere you can use one of them, you can use the other and get exactly the same result. A C compiler should generate exactly the same code for both. In practice, every C compiler that I have seen converts ptr[i] to *(ptr+i) at compile time, and then generates the code. (Well, actually, I once did see a compiler that generated different code, but it turned out to be a mutant PL/I compiler rather than a C compiler.) I suppose there might be some microscopic difference in compile speed between the two, but the runtime performance that most people worry about will be identical. This is one of the most frequently misunderstood parts of the C language. If you still aren't sure why the two expressions are equivalent, this would be a good time to go back and reread your C books. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Massachusetts has over 100,000 unlicensed drivers. -The Globe