Prev: integer
Next: shared memory question
From: Casper H.S. Dik on 4 Mar 2010 11:06 John Gordon <gordon(a)panix.com> writes: >To demonstrate, imagine that you intended to type this: > if (x == 7) >But you mistakenly typed this: > if (x = 7) >This is legal code but will not behave in the way you intended. >But if you had typed it this way: > if (7 = x) >The compiler will throw an error. But leaves you with unreadable code. You are using the wrong tools; proper tools will detect this. lint: (4) warning: assignment operator "=" found where "==" was expected and gcc: foo.c:4: warning: suggest parentheses around assignment used as truth value Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
From: ImpalerCore on 4 Mar 2010 11:11 On Mar 4, 10:52 am, John Gordon <gor...(a)panix.com> wrote: > In <oct467-nu6....(a)news.eternal-september.org> Richard <rgrd...(a)gmail.com> writes: > > > When discussing vars in computing it is normal to discuss the variables > > b name. > > You dont say "if pi is larger than p".You say "if p is larger than > > pi". You're style is nothing more than fancy for fancy's sake IMO. > > No, it does actually do something: it will throw a compile error if you > mistype == as =. > > To demonstrate, imagine that you intended to type this: > > if (x == 7) > > But you mistakenly typed this: > > if (x = 7) > > This is legal code but will not behave in the way you intended. > > But if you had typed it this way: > > if (7 = x) > > The compiler will throw an error. I prefer readability over a marginal technique to reduce bugs. English is meant to be read left to right, and is how I prefer to read code, not the Yoda style '7 == x'. If the potential bug really causes you grief, maybe pass a flag that makes the compiler flag 'x = 7' as warnings? > -- > John Gordon A is for Amy, who fell down the stairs > gor...(a)panix.com B is for Basil, assaulted by bears > -- Edward Gorey, "The Gashlycrumb Tinies"
From: Keith Thompson on 4 Mar 2010 11:20 Vladimir Jovic <vladaspams(a)gmail.com> writes: > Keith Thompson wrote: >> Vladimir Jovic <vladaspams(a)gmail.com> writes: >>> Scott Lurndal wrote: >>>> I personally place the condition operator at the front, as >>>> William does, but nested. >>>> >>>> if ((pointer1 != NULL) >>>> && (pointer1->field7 == 0x152)) { >>>> return; >>>> } >>> if ( ( pointer1 =! NULL ) >>> && ( pointer1->field7 = 0x152 ) ) { >>> return; >>> } >>> >>> ops && ops >> >> if ( pointer1 != NULL && >> pointer1->field7 == 0x152 ) >> { >> return; >> } >> [...] > > Yes, you missed the point. I prefer this way : > > if ( NULL != pointer1 && > 0x152 == pointer1->field7 ) > { > return; > } > > Can save you some debugging time :) Oh, I see. I noticed the use of "=!" for "!=" and "=" for "==", but assumed there were unintentional typos. ``pointer1 =! NULL'', of course, parses as ``pointer1 = !NULL''. ``!NULL'' evaluates to 1, and assigning an int value (other than a null pointer constant) to a pointer object requires a diagnostic. But yes, I'm familiar with the convention of putting the constant expression on the left hand side of a comparison operator, and with all the arguments in favor of it. Personally, I find it ugly. No offense. -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Casper H.S. Dik on 4 Mar 2010 11:27 Keith Thompson <kst-u(a)mib.org> writes: >``pointer1 =! NULL'', of course, parses as ``pointer1 = !NULL''. >``!NULL'' evaluates to 1, and assigning an int value (other than a >null pointer constant) to a pointer object requires a diagnostic. And for other types the compiler or lint will also create a diagnostic. (4) warning: assignment operator "=" found where "==" was expected (4) warning: constant operand to op: "!" >But yes, I'm familiar with the convention of putting the constant >expression on the left hand side of a comparison operator, and with >all the arguments in favor of it. Personally, I find it ugly. >No offense. Same here. Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
From: Rainer Weikusat on 4 Mar 2010 11:29
John Gordon <gordon(a)panix.com> writes: > In <oct467-nu6.ln1(a)news.eternal-september.org> Richard <rgrdev_(a)gmail.com> writes: >> When discussing vars in computing it is normal to discuss the variables >> b name. > >> You dont say "if pi is larger than p".You say "if p is larger than >> pi". You're style is nothing more than fancy for fancy's sake IMO. > > No, it does actually do something: it will throw a compile error if you > mistype == as =. > > To demonstrate, imagine that you intended to type this: > > if (x == 7) > > But you mistakenly typed this: > > if (x = 7) > > This is legal code but will not behave in the way you intended. It is a bad idea to try to solve social problems with technical means. The problem behind this is that = in C is a so-called 'false cognate' for people who are intimately familiar with mathematics, that is, a term in a foreign language which 'looks' very similar to a loosely related term in one's mother tongue, but with a (subtly) different meaning. This means that such people will likely confuse = and == in C intuitively and have a hard time spotting such an error since the text 'looks right' according to the set of conventions they are so used to that they no longer actively think about them. But this really only means that average people well-versed in mathematics shouldn't attempt to code in C because they will likely make basic errors other people wouldn't. |