tmh@well.UUCP (Todd M. Hoff) (06/16/89)
After a few lengthy arguments nobody could satisfactorly answer
this question:
What do you need to know to be an expert C programmer?
Any takers?
Todd
tmh@wellspl@mcnc.org (Steve Lamont) (06/16/89)
In article <12214@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes: >After a few lengthy arguments nobody could satisfactorly answer >this question: > > What do you need to know to be an expert C programmer? C. :-) -- spl Steve Lamont, sciViGuy EMail: spl@ncsc.org North Carolina Supercomputing Center Phone: (919) 248-1120 Box 12732/RTP, NC 27709
trebor@biar.UUCP (Robert J Woodhead) (06/16/89)
In article <12214@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes: > What do you need to know to be an expert C programmer? ``How to get paid for allegedly programming in "C"...'' -- Robert J Woodhead, Biar Games, Inc. !uunet!biar!trebor | trebor@biar.UUCP ``The worst thing about being a vampire is that you can't go to matinees and save money anymore.''
bright@Data-IO.COM (Walter Bright) (06/17/89)
In article <12214@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes:
<After a few lengthy arguments nobody could satisfactorly answer
<this question:
< What do you need to know to be an expert C programmer?
You need to be able to determine what the programs do that won the
Obfuscated C Code Contest *without* using a compiler!
:-) :-)
Note that I separate the concepts of knowledge and wisdom here, you
asked about knowledge!cline@suntan.ece.clarkson.edu (Marshall Cline) (06/17/89)
In article <2014@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes: >In article <12214@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes: >>After a few lengthy arguments nobody could satisfactorly answer >>this question: What do you need to know to be an expert C programmer? >You need to be able to determine what the programs do that won the >Obfuscated C Code Contest *without* using a compiler! :-) :-) >Note that I separate the concepts of knowledge and wisdom here, you >asked about knowledge! Walter's comment is insightful: let's realize the difference between knowledge and wisdom. Indeed, having knowledge is probably a necessary condition for being an expert, but no amount of knowledge can make one an expert unless the alleged expert can judge/discern between subtle distinctions, etc. Consider a large database containing all the valid `C' constructs and idioms. It might be argued that the database contains lots of `knowledge', but it (the database) clearly is NOT an `expert'. Thus the original poster asked the wrong question. It's not what you need to know, since NO volume of knowledge can make one an expert. [But this discussion probably belongs in "comp.lang.c.philosophy" :-)] Marshall -- ________________________________________________________________ Marshall P. Cline ARPA: cline@sun.soe.clarkson.edu ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline Clarkson University BitNet: BH0W@CLUTX Potsdam, NY 13676 AT&T: (315) 268-6591
cowan@marob.masa.com (John Cowan) (06/20/89)
In article <6057@microsoft.UUCP> paulc@microsoft.UUCP (Paul Canniff 2/1011) writes: >[A expert in C] can tell why the following code >prints "false" (on 8-bit char systems). > > char x = 0xff; > > if (x != 0xff) > printf("FALSE\n"); An expert in >portable< C, OTOH, knows that whether this code prints "FALSE" (not "false") is system-dependent, since whether chars are signed or unsigned is system-dependent. In fact, my program "mch.c", which is compiled on a given system to determine various system-dependent facts about it and print them out as a set of #defines uses logic much like this to decide whether chars are signed or unsigned. (Plug: Mch.c also determines the number of bits in ints, shorts, and longs, the number of bits in a char, and the appropriate byte ordering for the machine -- little-endian, big-endian, or mixed. It also makes a partial attempt to determine if the character set is ASCII, EBCDIC or something else.) -- John Cowan <cowan@marob.masa.com> or <cowan@magpie.masa.com> UUCP mailers: ...!uunet!hombre!{marob,magpie}!cowan Fidonet (last resort): 1:107/711 Aiya elenion ancalima!
ark@alice.UUCP (Andrew Koenig) (06/20/89)
In article <6057@microsoft.UUCP>, paulc@microsoft.UUCP (Paul Canniff 2/1011) writes: > How about ... understands why a[i] equals i[a] and CAN EXPLAIN IT, > knows what a trigraph is, and can tell why the following code > prints "false" (on 8-bit char systems). > char x = 0xff; > if (x != 0xff) > printf("FALSE\n"); ... or why it doesn't print anything at all on other 8-bit char systems. -- --Andrew Koenig ark@europa.att.com
Kevin_P_McCarty@cup.portal.com (06/20/89)
In <12214@well.UUCP>, tmh@well.UUCP (Todd M. Hoff) asks
> What do you need to know to be an expert C programmer?
The answer is in two parts, in order of importance:
1) You need to know software engineering:
data structures
algorithms
computer architectures
reliability
efficiency
2) You need to understand C:
why K&R says what it says
why X3J11 did what it did
Kevin McCartybilld@celerity.UUCP (Bill Davidson) (06/20/89)
In article <6057@microsoft.UUCP> paulc@microsoft.UUCP (Paul Canniff 2/1011) writes: >[an expert C programmer] can tell why the following code >prints "false" (on 8-bit char systems). > > char x = 0xff; > > if (x != 0xff) > printf("FALSE\n"); On a sign extending system with signed chars, it's because the signed char x is extended to be -1 and the "if" uses an int comparison with the int constant 0xff == 255. This does not have to work on all machines or compilers. Section 2.7 of K&R first edition (and section 6.1 of the C Reference Manual) allows chars to be either signed or unsigned and sign extension of chars is left as "hardware dependant". Shorts and int's must be sign extended. Only char's are left to the implementor. I tried this on 3 completely different kinds BSD machines with (I believe) pcc based compilers and it only printed "FALSE" on one of them. Section 2.7 of K&R second edition is the same on this. I can't seem to find the same stuff in the reference manual for the second edition. Section 6 changed quite a bit in organization. The point: the above code is implementation dependant and it is not portable to depend on having it work a certain way. P.S. It took me about 3 seconds (I read little slow :-) to find the right section in my tattered copy K&R1 and only had to look it up because I don't have the section numbers memorized and I wanted to refrence them so that the non-experts :-) out there can look it up. Does that qualify me as an expert :-). Bill Davidson ...!{ucsd,sdsu,fpssun,cogen,chip,photon}!celerity!billd
paulc@microsoft.UUCP (Paul Canniff 2/1011) (07/22/89)
In article <12214@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes: >After a few lengthy arguments nobody could satisfactorly answer >this question: > > What do you need to know to be an expert C programmer? > >Any takers? > > >Todd The obvious smug answer ... if you have to ask, you aren't. Sorry, couldn't resist. And I can't think of a really good, serious answer. I mean, how do you rate an expert? I consider myself pretty good, but sometimes I still check the operator-precedence charts. How about ... understands why a[i] equals i[a] and CAN EXPLAIN IT, knows what a trigraph is, and can tell why the following code prints "false" (on 8-bit char systems). char x = 0xff; if (x != 0xff) printf("FALSE\n"); ------------------------------------------------------------------ Disclaimer blah blah humorous statement blah blah Microsoft blah blah blah ... you get the idea.
jyegiguere@lion.waterloo.edu (Eric Giguere) (07/22/89)
In article <25999@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes: > Having the sign of chars be undefined allows the implementation to be as > efficient as possible with respect to converting between chars and ints. In article <4724@alvin.mcnc.org> spl@mcnc.org.UUCP (Steve Lamont) replies: > I > thought the standard was supposed to clarify things, not confuse the > issue. It's almost like saying that a declaration of int may be either > signed or unsigned. Makes for somewhat unpredictable behavior and/or > some fairly verbose defensive coding... As someone else pointed out, part of the "Spirit of C" is to be as efficient as possible without unduly constraining the users of the language... hence a 'char' can be signed or unsigned depending upon which fits a particular machine best... That said, the real reason why the pStandard does not specify that char should be signed or unsigned is that one of the overriding principles of the ANSI document is to not invalidate current programming practice.... the "new" C should be as upwardly-compatible as possible with the "old" C. Because many implementations had `char' as signed and many others had it as unsigned, the Committee chose to do nothing about the ambiguity. If you want a signed type and are using ANSI compilers, used 'signed char'. 'unsigned char' should work on all current C compilers.... but to get a signed char on some pre-ANSI machines you might actually have to fake it by going up to a short... Eric Giguere 268 Phillip St #CL-46 For the curious: it's French ("jee-gair") Waterloo, Ontario N2L 6G9 Bitnet : GIGUERE at WATCSG (519) 746-6565 Internet: giguere@aries5.UWaterloo.ca "Nothing but urges from HELL!!"
campbell@redsox.bsw.com (Larry Campbell) (07/22/89)
In article <12214@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes:
-
- What do you need to know to be an expert C programmer?
Who cares?
--
Larry Campbell The Boston Software Works, Inc.
campbell@bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146spl@mcnc.org (Steve Lamont) (07/22/89)
In article <6057@microsoft.UUCP> paulc@microsoft.UUCP (Paul Canniff 2/1011) writes: >In article <12214@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes: >> What do you need to know to be an expert C programmer? > [other "qualifications" deleted] > ... can tell why the following code >prints "false" (on 8-bit char systems). > > char x = 0xff; > > if (x != 0xff) > printf("FALSE\n"); The answer I assume you are looking for is that in the if-statement, the value of x is expanded to an int and, since it is declared char rather than unsigned char, the sign bit (high order) bit is propagated, making x == -1 decimal. This clearly differs from 0xff, which is, of course 255, decimal. However, when I tried this on my IRIS 4D to confirm my theory, I got the "wrong" answer. In other words, it did not print FALSE when run. My assumption is that the C compiler is not propagating the sign when promoting x to an int in the if-statment. (I don't read MIPS assembly code well enough to verify this) Is the Silly Graphics compiler broken, or is the behavior in the above code simply unpredictable? C "experts," what say you? (not an "expert", I just found the hat) -- spl Steve Lamont, sciViGuy EMail: spl@ncsc.org North Carolina Supercomputing Center Phone: (919) 248-1120 Box 12732/RTP, NC 27709
peter@ficc.uu.net (Peter da Silva) (07/22/89)
In article <6057@microsoft.UUCP>, paulc@microsoft.UUCP (Paul Canniff 2/1011) writes: > How about ... can tell why the following code prints "false" (on 8-bit char > systems). > char x = 0xff; > if (x != 0xff) > printf("FALSE\n"); If char is unsigned it doesn't. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
tim@crackle.amd.com (Tim Olson) (07/23/89)
In article <4722@alvin.mcnc.org> spl@mcnc.org.UUCP (Steve Lamont) writes: | In article <6057@microsoft.UUCP> paulc@microsoft.UUCP (Paul Canniff 2/1011) writes: | >In article <12214@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes: | >> What do you need to know to be an expert C programmer? | > [other "qualifications" deleted] | > ... can tell why the following code | >prints "false" (on 8-bit char systems). | > | > char x = 0xff; | > | > if (x != 0xff) | > printf("FALSE\n"); You also need to know why the statement above is not necessarily true ;-) | The answer I assume you are looking for is that in the if-statement, the | value of x is expanded to an int and, since it is declared char rather | than unsigned char, the sign bit (high order) bit is propagated, making | x == -1 decimal. This clearly differs from 0xff, which is, of course 255, | decimal. Chars are not necessarily signed by default. Many implementations make chars unsigned. This is the reason why the "signed" keyword was added to ANSI C. Having the sign of chars be undefined allows the implementation to be as efficient as possible with respect to converting between chars and ints. -- Tim Olson Advanced Micro Devices (tim@amd.com)
spl@mcnc.org (Steve Lamont) (07/23/89)
In article <25999@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes: >In article <4722@alvin.mcnc.org> spl@mcnc.org.UUCP (Steve Lamont) writes: >| In article <6057@microsoft.UUCP> paulc@microsoft.UUCP (Paul Canniff 2/1011) writes: > [various and sundry bits deleted] >Chars are not necessarily signed by default. Many implementations make >chars unsigned. This is the reason why the "signed" keyword was added >to ANSI C. > >Having the sign of chars be undefined allows the implementation to be as >efficient as possible with respect to converting between chars and ints. Huh? Are you telling us that the standard *allows* such a horrible thing? Aaaaaaarrrrrgh! :-+ (<-- smiley sucking on a persimmon) I thought the standard was supposed to clarify things, not confuse the issue. It's almost like saying that a declaration of int may be either signed or unsigned. Makes for somewhat unpredictable behavior and/or some fairly verbose defensive coding... -- spl Steve Lamont, sciViGuy EMail: spl@ncsc.org North Carolina Supercomputing Center Phone: (919) 248-1120 Box 12732/RTP, NC 27709
charlie@mica.stat.washington.edu (Charlie Geyer) (07/23/89)
In article <25999@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes: > Having the sign of chars be undefined allows the implementation to be as > efficient as possible with respect to converting between chars and ints. In article <4724@alvin.mcnc.org> spl@mcnc.org.UUCP (Steve Lamont) replies: > Huh? Are you telling us that the standard *allows* such a horrible > thing? Aaaaaaarrrrrgh! :-+ (<-- smiley sucking on a persimmon) I > thought the standard was supposed to clarify things, not confuse the > issue. It's almost like saying that a declaration of int may be either > signed or unsigned. Makes for somewhat unpredictable behavior and/or > some fairly verbose defensive coding... C is "hardware friendly." The standard has been written by some very clever people to allow C to be implemented as efficiently as possible on almost any hardware no matter how brain damaged. It's not a bug, it's a feature.
henry@utzoo.uucp (Henry Spencer) (08/13/89)
In article <4724@alvin.mcnc.org> spl@mcnc.org.UUCP (Steve Lamont) writes: >>Having the sign of chars be undefined allows the implementation to be as >>efficient as possible with respect to converting between chars and ints. > >Huh? Are you telling us that the standard *allows* such a horrible >thing? Aaaaaaarrrrrgh! :-+ (<-- smiley sucking on a persimmon) I >thought the standard was supposed to clarify things, not confuse the >issue... I see it's time to repost my commentary on this from some time ago: ----------- All potential participants in this debate please attend to the following. - There exist machines (e.g. pdp11) on which unsigned chars are a lot less efficient than signed chars. - There exist machines (e.g. ibm370) on which signed chars are a lot less efficient than unsigned chars. - Many applications do not care whether the chars are signed or unsigned, so long as they can be twiddled efficiently. - For this reason, char is intended to be the more efficient of the two. - Many old programs assume that char is signed; this does not make it so. Those programs are wrong, and have been all along. Alas, this is not a comfort if you have to run them. - The Father, the Son, and the Holy Ghost (K&R1, H&S, and X3J11 resp.) all agree that characters in the "source character set" (roughly, those one uses to write C) must look positive. Actually, the Father and the Son gave considerably broader guarantees, but the Holy Ghost had to water them down a bit. - The "unsigned char" type exists (in most newer compilers) because there are a number of situations where sign extension is very awkward. For example, getchar() wants to do a non-sign-extended conversion from char to int. - X3J11, in its semi-infinite wisdom, has decided that it would be nice to have a signed counterpart to "unsigned char", to wit "signed char". Therefore it is reasonable to expect that most new compilers, and old ones brought into conformance with the yet-to-be-issued standard, will give you the full choice: signed char if you need signs, unsigned char if you need everything positive, and char if you don't care but want it to run fast. - Given that many compilers have not yet been upgraded to match even the current X3J11 drafts, much less the final endproduct (which doesn't exist yet), any application which cares about signedness should use typedefs or macros for its char types, so that the definitions can be revised later. - The only things you can safely put into a char variable, and depend on having them come out unchanged, are characters from the native character set and small *positive* integers. - Dennis Ritchie is on record, as I recall, as saying that if he had to do it all over again, he would consider changing his mind about making chars signed on the pdp11 (which is how this mess got started). The pdp11 hardware strongly encouraged this, but it *has* caused a lot of trouble since. It is, however, much too late to make such a change to C. ----------- -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
cpcahil@virtech.UUCP (Conor P. Cahill) (08/13/89)
In article <4722@alvin.mcnc.org>, spl@mcnc.org (Steve Lamont) writes: > > However, when I tried this on my IRIS 4D to confirm my theory, I got the > "wrong" answer. In other words, it did not print FALSE when run. My > assumption is that the C compiler is not propagating the sign when > promoting x to an int in the if-statment. (I don't read MIPS assembly > code well enough to verify this) > The problem may be that the char data type may be unsigned by default. This was true on the 3b2 when it first came out (I'm not sure if it is still true, but on the original machines there was no way to make a signed character). This wrecked havoc on an office automation product that was being ported to the system because lots of code expected 0xff in a character to equal -1 in an integer. The final answer is that the branch in that code is implementation dependent. I'm not sure if this issue is addressed in the ANSI standard, but one would hope that it was.
hascall@atanasoff.cs.iastate.edu (John Hascall) (08/15/89)
In article <6057> paulc@microsoft.UUCP (Paul Canniff 2/1011) writes: }In article <12214@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes: }> What do you need to know to be an expert C programmer? } I mean, how do you rate an expert? I consider myself }pretty good, but sometimes I still check the operator-precedence }charts. That's because they don't make sense. }How about ... understands why a[i] equals i[a] and CAN EXPLAIN IT, a[i] = *(a+i), i[a] = *(i+a), a+i = i+a }knows what a trigraph is, A crock...
henseler@uniol.UUCP (Herwig Henseler) (08/16/89)
> }> What do you need to know to be an expert C programmer? > }How about ... understands why a[i] equals i[a] and CAN EXPLAIN IT, That's really nice, but not all compiler are willed to compile it... Another nice example: int i = 0; i += ++i + i++; printf( "%d\n", i ); Now explain what can happen..... Solution: Every number between 1 and 5 (inclusive) is legal! Our compiler produces '5' and I had to look at the machine-code to figure out why: i += ++i + i++; expands to (our compiler evaluates from left to right): /* a. b. c. */ i = ++i + i++ + i; First i is incremented at pos. a, i equals 1 and is incremented at pos. b. Now position b evaluates to 1 and pos a to 2 (!! strange but legal !!). At pos. c i has the value 2. Now 2+1+2 results in 5. Voila! (The explanation of the four other possible results are left as an exercise for junior C-experts :-) bye, Herwig -- ** Herwig Henseler (CS-Student) D-2930 Varel, Tweehoernweg 69 | Brain error- ** ** EMail: henseler@uniol.UUCP (..!uunet!unido!uniol!henseler) | core dumped **
jeffrey@algor2.uu.net (Jeffrey Kegler) (08/18/89)
In article <757@uniol.UUCP> henseler@uniol.UUCP (Herwig Henseler) writes: > > int i = 0; > i += ++i + i++; > printf( "%d\n", i ); > >Every number between 1 and 5 (inclusive) is legal! Along with a bunch of others. The ANSI C standard says the above is undefined (3.3, with footnote and A.6.2). This means anything may happen. In particular, any number or no number may be printed. Actually, the sentence stating this is somewhat mysterious. "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of the expression." The footnote and appendix make it clear that it is intended that expression like the example make a program undefined. But they are not supposed to be part of the Standard, and if the sentence is read alone, it yields other interpretations. More obvious than its intended meaning is that an expression like the example is legal, yields an implementation dependent result, and, if interrupted by a signal, must either have its initial value or that result. In fact, I do not think the sentence, taken alone, says what it is intended to mean. If we generalize to longer expressions without sequence points, such as i = 15 + (j = i++ + j++ + (i = j++ ... ad nauseam ) ) this imposes impressive requirements on a comforming implementation. -- Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc. jeffrey@algor2.ALGORISTS.COM or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
dem@mead.UUCP (Dave Myers) (08/24/89)
In article <1336@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu.UUCP (John Hascall) writes: >In article <6057> paulc@microsoft.UUCP (Paul Canniff 2/1011) writes: >}In article <12214@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes: > >}> What do you need to know to be an expert C programmer? > >}How about ... understands why a[i] equals i[a] and CAN EXPLAIN IT, > > a[i] = *(a+i), i[a] = *(i+a), a+i = i+a > Hmmm.... I don't claim to be a C expert, but let's take a trivial case. An array of anything with a size different from that of int will do. int i; struct element { int x[BIGNUMBER]; } a[WHATEVER]; a[i] == *(a + (i * sizeof(element))) i[a] == *(i + (a * sizeof(int))) or a[i] == *(a + (i * sizeof(int) * BIGNUMBER)) i[a] == *(i + (a * sizeof(int))) Clearly, these are not equal. By the same (or at least a similar) token, if you do, struct element *b; i = b; i++; b++; printf("%d", i == b); you will get a 0, meaning that i and b were not incremented by the same amount. -- David Myers (513) 865-1343 Mead Data Central This Data Fabrication Technology P.O. Box 933 space mead!dem@uccba.uc.edu Dayton, Ohio 45401 available. ...!uccba!mead!dem
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/25/89)
In article <338@mead.UUCP> dem@mead.UUCP (Dave Myers) writes: > i[a] == *(i + (a * sizeof(int))) Wrong.
merlyn@iwarp.intel.com (Randal Schwartz) (08/25/89)
In article <338@mead.UUCP>, dem@mead (Dave Myers) writes: [...] | Hmmm.... I don't claim to be a C expert Obviously not, because.... :-) | , but let's take a trivial | case. An array of anything with a size different from that of int | will do. | | int i; | struct element { | int x[BIGNUMBER]; | } a[WHATEVER]; | | a[i] == *(a + (i * sizeof(element))) | i[a] == *(i + (a * sizeof(int))) Both of these lines are wrong. a[i] = *(a + i) since 'a' is a pointer, and 'i' is an integer, 'a+i' is the same as executing a++ for 'i' times (or a-- for '-i' times if i<0). i[a] = *(i + a) since 'a' is a pointer, [this will sound familiar], and 'i' is an integer, 'i+a' is the same as executing a++ for 'i' times (or a-- for '-i' times if i<0). See, it's the same thing! The scaling happens during the "addition" (which isn't really addition) of a pointer and an integer BY DEFINITION. This definition just happens to make the array "operator" commutative. Just another longtime C hacker, (and no, I don't write i[a], but I could! :-) -- /== Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ====\ | on contract to Intel, Hillsboro, Oregon, USA | | merlyn@iwarp.intel.com ...!uunet!iwarp.intel.com!merlyn | \== Cute Quote: "Welcome to Oregon... Home of the California Raisins!" ==/
ark@alice.UUCP (Andrew Koenig) (08/25/89)
In article <338@mead.UUCP>, dem@mead.UUCP (Dave Myers) writes: -> -> In article <1336@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu.UUCP (John Hascall) writes: -> >In article <6057> paulc@microsoft.UUCP (Paul Canniff 2/1011) writes: -> >}In article <12214@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes: -> > -> >}> What do you need to know to be an expert C programmer? -> > -> >}How about ... understands why a[i] equals i[a] and CAN EXPLAIN IT, -> > -> > a[i] = *(a+i), i[a] = *(i+a), a+i = i+a -> > -> -> -> Hmmm.... I don't claim to be a C expert, but let's take a trivial -> case. -> a[i] == *(a + (i * sizeof(int) * BIGNUMBER)) -> i[a] == *(i + (a * sizeof(int))) -> -> Clearly, these are not equal. You're right, you're not a C expert. a[i] and i[a] truly are identical. I'll leave it to you to figure out which of your two `equivalences' aren't. -- --Andrew Koenig ark@europa.att.com
dem@mead.UUCP (Dave Myers) (08/27/89)
In article <4847@omepd.UUCP> merlyn@iwarp.intel.com (Randal Schwartz) writes: >In article <338@mead.UUCP>, dem@mead (Dave Myers) writes: >[...] >| Hmmm.... I don't claim to be a C expert Here I go on to prove it. :) >| i[a] == *(i + (a * sizeof(int))) >... The scaling happens during the "addition" >(which isn't really addition) of a pointer and an integer BY >DEFINITION. This definition just happens to make the array "operator" >commutative. I am enlightened. Or rather, I realize I probably should have figured it out if I had thought harder, but I didn't. Thank you for the correction. > Just another longtime C hacker... Just another shorttime C/C++ progammer. -- David Myers (513) 865-1343 Mead Data Central This Data Fabrication Technology P.O. Box 933 space mead!dem@uccba.uc.edu Dayton, Ohio 45401 available. ...!uccba!mead!dem