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

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.

--
- Mark ->
--
Reply to
Mark A. Odell
Loading thread data ...

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??
 Click to see the full signature
Reply to
Grant Edwards

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.
Reply to
buddy.spaminator.smith

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

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

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

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

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
 Click to see the full signature
Reply to
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.

Reply to
engr

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...
Reply to
Darin Johnson

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."

Reply to
Ben Bradley

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
 Click to see the full signature
Reply to
Grant Edwards

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
 Click to see the full signature
Reply to
Grant Edwards

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

Reply to
Christopher Fairbairn

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

;)

--
Grant Edwards                   grante             Yow!  Now I'm telling MISS
                                  at               PIGGY about MONEY MARKET
 Click to see the full signature
Reply to
Grant Edwards

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"
Reply to
Darin Johnson

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.

--
Morris Dovey
West Des Moines, Iowa USA
 Click to see the full signature
Reply to
Morris Dovey

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.
 Click to see the full signature
Reply to
CBFalconer

Nope ... we invent COBOL so they can read it. Of course, they

*STILL* don't understand it ...

George

Reply to
George Neuner

Not true. At least with the compilers that I've used. Expressions are by default non-zero, not "1" or "-1" or specifically any other non zero number.

Better to do:

typedef enum { FALSE = 0, TRUE, } BOOL;

At least the compiler can type check when you use a real boolean.

-->Neil

Reply to
Neil Bradley

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.

-->Neil

-->Neil

Reply to
Neil Bradley

OK, it's been over a decade since I used Pascal, so... :-) Was this a part of a Pascal standard, or an extension?

--
Darin Johnson
    My shoes are too tight, and I have forgotten how to dance -- Babylon 5
Reply to
Darin Johnson

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.