Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uunet!unisoft!greywolf From: greywolf@unisoft.UUCP (The Grey Wolf) Newsgroups: comp.lang.c Subject: Re: Dealing with pointer freaks Message-ID: <3543@unisoft.UUCP> Date: 28 Jun 91 06:47:24 GMT References: <6470@goanna.cs.rmit.oz.au> <2075@manta.NOSC.MIL> Reply-To: greywolf@unisoft.UUCP (The Grey Wolf) Distribution: comp Organization: Foo Bar and Grill Lines: 84 /* by mikeg@c3.c3.lanl.gov (M. P. Gerlek) * * In article sherman@unx.sas.com (Chris Sherman) writes: * > IMHO, leave the dude alone. Jump up and down when you find major problems * > [...] * > but for things like *(x+i), don't worry about it. * * Yes, x[i] is just *(x+i), but consider what x[a][b+k][j+1] turns into. * I can't believe more than a handful of you could look at the * "pointer-ized" expression for x[a][b+k][j+1] and *immediately* tell * what it means. We're considering readability of code, here. What, you mean *(*(*(x+a)+(b+k))+(j+1))? Makes perfect sense, what's the matter? :-) In all seriousness, from my own (probably insignificant) point of view, how it is done depends largely upon how it is declared. For "propriety's" sake, I guess I'm kind of a purist: If it's a pointer, use offsets. If it's an array, use indeces. That's just my own style, tho'. It reminds me of precisely that with which I am dealing. * As an example, consider coding some sort of numerical, linear algebra * sort of algorithm. The mathematical expression can be fairly quickly * translated into C, substituting x-sub-i-sub-j ("x_ij") for x[i][j]. * It's not obvious to the subsequent reader of the code that the * expression *(*(x+i)+j) is simply x[i][j], however. You've lost * 'readability'. Depends upon the person to whom you hand the code. Admittedly it does get hairy when you start getting into triple-indirections (or worse). * * Yes, I will grant that if the piece of code you are doing is a * one-man project you can code it however you like -- but what happens * after you've left the shop, and someone else needs to use it? Ummm...no, wait... "if it was hard to write, it should be hard to understand?" :-) Well, yes, that does produce a problem. Again, there is the problem of: Never mind anyone else yet, first things first: Will >>>>YOU<<<< understand the code in a week, a month, six months from now? * Further, to get back to my original post, we're dealing with a case * where the programmer is programming solo _today_, but will be writing * code that he and others will have to port and modify _tomorrow_. * He says he'll deal with it then; let him worry about it. It's his ass if he fucks up, not yours. * Finally, I've gotten responses saying that the Indian Hill style guide * is out-of-date and flat out wrong in places. Will someone please post * a critique of the I.H. guide? And please tell me what y'all use * instead? If anything? I'm interested as well. * * And as an aside to those of you who don't like "conventions" and * "styles" in C: do you put your #defined constants in all uppercase? * You do? Care to explain why? So I can tell the difference between a constant and a variable, usually. I leave macros lowercase, though. * * -[mpg] * mikeg@lanl.gov * "Headline: LANL High-speed Compooter Researchers Pay Raft Trip Subsidies" * -- * * -[mpg] * mikeg@lanl.gov * "Headline: LANL High-speed Compooter Researchers Pay Raft Trip Subsidies" Is there an echo in here? -- "Is 'Faxen' the plural of 'Fax', or is it 'Faces'?" -- # "Religion is a weapon invented by the sheep to keep the wolves in line." # greywolf@unisoft.com