Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!vsi1!ubvax!ardent!mec From: mec@ardent.UUCP (Michael Chastain) Newsgroups: comp.lang.c Subject: Re: Array indexing vs. pointers... Summary: Pretend they're equal cost. Just write the most natural code. Message-ID: <607@ardent.UUCP> Date: 24 Sep 88 09:45:51 GMT References: <8809191521.AA17824@ucbvax.Berkeley.EDU> <68995@sun.uucp> <23025@amdcad.AMD.COM> Organization: Ardent Computer Lines: 63 Good grief. Say NO to low-level performance tweaking. I prefer to use the most natural data representation I can think of. If something's an array, I don't dink around inside it with pointers. More precisely, I restrict my pointer operations to: -- assignment/parameter passing/return value -- dereferencing -- address-of: p2 = &p1[5]; As another poster mentioned: /* Array */ for ( iArg = 1; iArg < argc; iArg++ ) ProcessArg( argv[iArg] ); /* Pointer */ while ( --argc ) ProcessArg( *++argv ); I find the first version more writeable. More debuggable. More readable. And more likely to be correct *the first time*. If you had to debug this code with a typical sdb-like debugger, which would you rather look at? "iArg" or "argv"? I find wild array references easier to deal with than wild pointer references: less likely to occur, easier to debug/find when they do. I find all of these properties more useful than the small and doubtful performance gain that I can get by *increasing the entropy* of my code and data. Suppose you told your boss: "my next project will be: -- 20% sooner -- 20% cleaner -- 30% less bugs -- 5% larger -- 5% slower (in non-real-time-critical areas)" What do you think he or she would say? #if FLAME The last word for you efficiency geeks: #if BIG_COMPUTER My array code vectorizes more easily than your pointers-that-might-be- aliased code. So while you're saving a cycle here, a cycle there, I'm getting 400% performance improvements just by recompiling. #endif #if INTEL_8086 While your object code is thrashing via ES:BX, my object code is loading ES:BX with a fixed value and loading array indexes into SI and DI. And if you point a normal 32-bit pointer into global data or a stack, while I'm using an array index into a (sufficiently well-known) structure, my code is likely to get 16-bit address computations off of DS or SS:BP. Your code will thrash through ES:BX. #endif #endif FLAME Michael Chastain mec@ardent.com {hplabs,uunet}!ardent!mec "He who dies with the most FRIENDS wins."