Question About Strange 'C' Code Syntax ( Well strange to me anyway )

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??

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

In article , Spehro Pefhany writes

There are no 9899:1999 conforming compilers (OK, so 2 claim it) the majority are 9899:1990 + A1 IE 9899:1996

However as the discussion is about PIC compilers you are not going to get a conforming compiler anyway.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

In article , Spehro Pefhany writes

Your not going to get very far in embedded engineering if you keep using that line. BTW which compiler do you know that are 9899:1999?

Embedded compilers do a lot of non standard things. Especially in the 8 bit areas.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

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

(Snip)

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);

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

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.

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??

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?

c = a + b;

Thanks, Christopher Fairbairn

switch (a+b) { case 0: c = ZERO; break; case 1: c = ONE; break; case 2: c = TWO; break; default: c= MANY; break; }

;)

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.

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 d)) OR (e = f); myint := ord(NOT mybool);