Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!titan!preston From: preston@titan.rice.edu (Preston Briggs) Newsgroups: comp.lang.misc Subject: Re: C Pointers Message-ID: <5955@brazos.Rice.edu> Date: 22 Mar 90 02:58:46 GMT References: <8432@hubcap.clemson.edu> <5200048@m.cs.uiuc.edu> <5919@brazos.Rice.edu> <14823@pur-ee.UUCP> Sender: root@rice.edu Organization: Rice University, Houston Lines: 55 In article <14823@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes: >In article <5919@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes: >> x = y + i; >>This means assign the sum of y and i*5. Not too bad, 1 shift and 3 adds. I mean 2 adds. >> j = x - y; >>Hmmm. A subtract and a DIVISION by 5!? >True, but so what? I think a lot of C pointer fiends write a lot of code deliberately using pointer arithmetic and then saying proudly: "Look, only adds and subtracts! Must be fast." I was trying to say that lots of pointer arithmetic is an ugly way to achieve no extra efficiency, and in fact to occasionally get bit badly. I'm familier with the bite; it's happened to me. I had a pretty little set manipulation package I used in my register allocator. One day I looked at the assembly. A call to the divide routine!? "What's all this then! I don't do division. Division is for dumb people." After we noticed what was happening and massively rewriting chunks of the allocator, we got a factor of three improvement in code generation time. >The only aspects in which C pointers are harder to >analyze than Fortran array references are: > >[1] C pointers can be multi-level, i.e., pointers-to-pointers. >[2] C supports recursion, hence pointers/subscript expressions can be > more difficult to decipher. I think C's pointer are used for too much. If we want array-like behaviour, we should use arrays. If we want interesting, dynamic structures, we should use recursive data types. C uses pointers for both. I would rather not use pointers at all. >Well, I usually agree with you, Preston, but I think your "Fortran is easy >to understand" bias is showing on this one. ;-) > -hankd@ecn.purdue.edu Ah, the "F word". I hate fortran! I don't use it. I (almost) never have. However, I do like constructs that are easy to optimize. :-) -- Preston Briggs looking for the great leap forward preston@titan.rice.edu