Dealing with pointer freaks

[The Grey Wolf]

/* <MIKEG.91Jun25093137 at c3.c3.lanl.gov> by mikeg at c3.c3.lanl.gov (M. P. Gerlek)
 * 
 * In article <sherman.677844151 at foster> sherman at 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 at lanl.gov
 *  "Headline: LANL High-speed Compooter Researchers Pay Raft Trip Subsidies"
 * --
 * 
 * -[mpg]
 *  mikeg at 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 at unisoft.com