Possibilities of Return (with parameters???)

[Leor Zolman]

...unless the function is called with no arguments, in which case () is
clearly unary postfix. ;-)

Ha! I was just thinking about that this morning, that what I really
/should/ have said was:

"and () is...well, sometimes unary and sometimes other things"

;-)
-leor

 

[Leor Zolman]

Some of C's operator precedences are downright screwy, and
I confess to some confusion even after two and a half decades'
experience with the language.

After 25 years of dealing with C operator precedence, and 15
years of teaching about it, this is how I distill the precedence
table to what I think are the bare essentials:

For binary operators:

0. Selection/flow control have highest precedence (. -> () [] )
1. My Dear Aunt Sally is next
2. Assignment is very, very low (only the "lowly" comma operator
is lower)
3. All binary operators associate L-to-R, except assignment

Unary operators:

1. Very high precedence (beaten only by selection/flow control
above) and R-to-L associative (or, alternatively, postfix
has higher precedence)

Those are the things worth memorizing, but I never make students
memorize anything about the precedence table (it is always
available open-book, unless I just post it up somewhere in the
room.)

Any code that cannot be /clearly/ resolved by one of the above
rules should be explicitly parenthesized, whether it needs to or
not. And sometimes even code that /can/ be, should be
parenthesized (strange combinations of My Dear Aunt Sally
subexpressions, for example).

I posit that well-written code should never force someone who
has learned the above rules to have to go scrambling for a
precedence table.

Very nice. You have regularized my generic mumblings about "use
more parentheses" into a very usable (and teachable) set of
rules. Your rules could also be incorporated into a lint or
lint-like utility to scan source for possibly confused statements.

Thanks. After writing this up (I hadn't really collected all of those
thoughts in one place before and written them down, I'd just been
dispensing the advice in little quanta), I think I'd add one more
section to the binary operators in order to avoid implying parens are
needed in a case where many would say they're not.

Between 1. and 2., add a 1.5:

1.5 Simple binary relational ops (==, !=, <, <=, >, >=) have
precedence over the logical connectives (&& and ||).

What this constitutes is basically a "My Dear Aunt Sally" rule for
logical operators. I'd typically write:
if (a==b && c==d)
rather than
if ((a == b) && (c ==d))
although some might disagree. This one is less black&white than all
the others, I think.
-leor

 

[Orhan Kavrakoglu]

Some of C's operator precedences are downright screwy, and
I confess to some confusion even after two and a half decades'
experience with the language.

After 25 years of dealing with C operator precedence, and 15 years of
teaching about it, this is how I distill the precedence table to what I
think are the bare essentials:

For binary operators:

0. Selection/flow control have highest precedence (. -> () [] )

1. My Dear Aunt Sally is next

2. Assignment is very, very low (only the "lowly" comma operator is lower)

3. All binary operators associate L-to-R, except assignment

Unary operators:

1. Very high precedence (beaten only by selection/flow control above) and
R-to-L associative (or, alternatively, postfix has higher precedence)

Here's my very short list of rules:

1. Things in parantheses have predecence over things that are not.

Then again, I don't know many of the predecence rules off the top of
my head and am known to modify existing ambigious-looking code (even
if I'm only reading it.)

IMHO it is good coding style to use parantheses, or at least
"informative whitespace" in such situations:

if ((a == b) || (c == d))

is almost as good as

if (a==b || c==d)

which is much better than

if (a== b||c ==d)

 

[CBFalconer]

.... snip ...

Between 1. and 2., add a 1.5:

1.5 Simple binary relational ops (==, !=, <, <=, >, >=) have
precedence over the logical connectives (&& and ||).

What this constitutes is basically a "My Dear Aunt Sally" rule
for logical operators. I'd typically write:
if (a==b && c==d)
rather than
if ((a == b) && (c ==d))
although some might disagree. This one is less black&white than
all the others, I think.

My rule for logical is that they have lower precedence than
arithmetical, and must be fully parenthized. So I would always
use your second example above. Nothing to remember.

 

[Dan Pop]

My rule for logical is that they have lower precedence than
arithmetical, and must be fully parenthized.

It depends on what you mean by arithmetical operators...

Dan

 

[Leor Zolman]

It depends on what you mean by arithmetical operators...

Heh. I was almost ready to blast you for invoking someone's poor command of
the English language ;-)

Then I actually began researching this, and was surprised to find no actual
mention of binary arithmetic operators at all, except implicitly as a
section of the index (p. 519) that contains some operators I'm sure Chuck
was /not/ meaning to include in his usage above.

And I always thought "arithmetic operators" was safely synonymous with the
My Dear Aunt Sally operators + mod. Sheesh.
-leor