snipped-for-privacy@ieee.org.invalid wrote in news:bnb65g$t8v$ snipped-for-privacy@news-int.gatech.edu:
No need, ?: is near the bottom of the precedence barrel, == (much higher in precedence) gets evaluated first, then the trinary goes to work, finally the lowly assignment operator. Only the sequence operator (,) is below assignment.
I think the first example is much clearer. The intent is to set the variable c to the result of the boolean expression (a==b), and that's exactly what the original line of code does -- they even paranthised it to make it clearer. Why spread it out over 4 lines of code and require me to go look up TRUE and FALSE in some header file somewhere??
--
Grant Edwards grante Yow! Where's th' DAFFY
at DUCK EXHIBIT??
Mark A. Odell wrote: : snipped-for-privacy@ieee.org.invalid wrote in : news:bnb65g$t8v$ snipped-for-privacy@news-int.gatech.edu: : :> Mark A. Odell wrote: :> :>: c = a == b ? !0 : 0; :> :> Where's a good gun when i need it.... :> :> you should at LEAST use ( ) around that... : : No need, ?: is near the bottom of the precedence barrel, == (much higher
I meant for clarity... it's much easier to see what's going on with explicit ( ) around the equality test. I prefer code that I can glance at and see what's going on, without having to read the whole line. ( ) enable that to happen more easily. and i'm no LISP user :)
Using the ternary (not 'trinary') operator without parenthesis is no cleaner than the orginal c = (a == b). now, c = a == b should be taken out and shot :)
ttyl,
--buddy
--
Remove '.spaminator' and '.invalid' from email address
when replying.
I've gotten just about far enough, thanks. ;-) The point is it's "supposed" to be an int, from K&R I to present. It indeed probably is a char in PIC compilers.
True, such as probably using a smaller scalar integral type, in this case.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Because the first example requires a different way of thinking, and it's not the way the majority of people think. It's more of a "hotshot" way of thinking. I'm not saying it's bad, but if the code may be maintained by others in the future, then it should be written in the 2nd method.
I don't think it's a hotshot way of thinking. Maybe if you use "a", "b", and "c" as variable names it's obtuse, but if you use more realistic names it can be clear. Such as: matchFound = (index == key);
--
Darin Johnson
Luxury! In MY day, we had to make do with 5 bytes of swap...
I'll bet a dollar that FALSE is always defined as 0 or NULL or some such equivalent. I won't bet on the value of TRUE other than it's not
0 nor NULL.
Perhaps the difference of opinion can be traced to how you learned C and even what you were exposed to before learning it. I learned APL (a compact language with lots of powerful operators) in college, and every operator (except parentheses, which are used conventionally) returns a value, including comparison operatiors and the assignment operator. Furthermore, evaluation (except for operator precedence) is right to left. I think knowing that helped me when I learned C and read that '=' returns a value just as '==' and '!=' do (I even recall being able to do c=(a=b) in Basic, and c=a.eq.b in ... sorry, language drift). Seeing the first method is like seeing a multisyllabic word whereas the second is like a long sentence describing what the word means. What was that Reader's Digest column, "It pays to increase your word [/syntax] power."
I guess it requires you to think like a programmer.
We're not talking about the majority of people. The majority of people can't read C period. Or any other programming languages. We aren't going to stop writing software, to please the majority of people, are we?
I can't agree. The concept of a boolean express is _so_ basic to computer science that "banning" it would be silly.
--
Grant Edwards grante Yow! I hope the
at "Eurythmics" practice birth
Maybe, but why have to bet at all? We _know_ what the value of (a==b) can be: 0 or 1. We don't have to guess, or bet, or look it up somewhere.
I suppose if you had only used programming languages which didn't have a comparison operator, you might be confused the first time you saw one. I can't think of any languages that don't, though.
If a comparison operator didn't return a value, what would be the point of having one??
[...]
--
Grant Edwards grante Yow! Finally, Zippy
at drives his 1958 RAMBLER
I bileve that every one can agree that something like
if (a > b) { ... }
is ok, so where's the big leap to
c = (a > b);
and from there to
c = (a == b);
I must admit while I was learning C that the concept was slightly strange to me, but by the same token learning a new language always presents slightly different takes on the same subject area.
Once you get it into your head that operators such as and == are basically treated the same as +, -, and * etc I don't see the need to expand it over multiple lines into an if/then/else kind of statement. All you are doing is saying, if this is true the answer is true, if this is false the answer is false, i.e. needless duplication.
You wouldn't suggest the following needs expansion would you?
I think a lot of people are stuck on the stereotypical Pascal style of conditionals that can only appear in IF or WHILE statements. Many languages break out of that mold, such as Lisp for instance, where _of_ _course_ operators return actual values. C allows this to happen as well, but it is more common to see it used with only a procedural style and maybe this confuses people who have only seen that style.
--
Darin Johnson
"Particle Man, Particle Man, doing the things a particle can"
Note, however, that Harvey did specify "'C' Code Syntax" in the subject of his post. If == produces a value other than a zero or one, then the compiler is /not/ a C compiler - and this fact is not altered by the hardware on which the program executes.
All bets are off if you're compiling C code with other than a C compiler :-P
One of my favorite single-statement C functions takes advantage of this (rather limited) range of values produced by C's relational operators:
int signof(int x) { return (x > 0) - (x < 0); }
To produce 1 if (x > 0), 0 if (x == 0), and -1 if (x < 0). I don't need/use it very often; but haven't found a C compiler yet that doesn't compile the expression to produce correct results.
This is nonsense. Pascal can have any form of conditional expression you please. You can even convert the result into numerics (with ord()) yielding 0 or 1.
mybool := ((a < b) AND (c > d)) OR (e = f); myint := ord(NOT mybool);
However IF, WHILE, UNTIL statements must be followed by a logical expression rather than any arithmetic expression, which may be where the confusion arises.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
It may be concise but it isn't clear when scanning code (= looks like == when scanning code you're unfamiliar with). It's better to be explicit about it than save typing. I've seen lots of obscure bugs get induced when the intent of the author was not clear in his code.
Which also takes 3 readings to figure out what it's supposed to do by anyone who isn't familiar with the code overall. It doesn't read well and it doesn't show intent. And if you have to go look at the book or remember operator precedence, you've already failed the readability and maintainability aspect.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.