How about:Generally; if in doubt you can always inspect the precedence
table that you find in K&R and elsewhere. Below some hints to
hopefully reduce your confusion...
* What is the order here: a ^ b | cPersonally I don't think that there's a prevalent definition
how these should be ordered. - But note the history of these
operators, which was BTW why they are in "C" at the positions
that they are; their (potential) use as boolean sets.
To memorize the bit-value operations you can associate them
with the glyphs for the boolean operations; per convention
AND (&&) comes before OR (||), and insert the bitwise xor in
between. - As said; there's a rationale for the choice, and
a historic explanation (that makes sense), but you can in
case of doubt or to make things clearer also use parentheses.
* Why do bitwise & | ^ need their own level anywayFor historic reasons of potential use. (As said above.)
* What is most intuitive precedence here: a << 3 + b, and whatWhat it is in "C" you should look up in the precedence table.
is it in C
What it is intuitively depends on what the programmer wanted to
express. As it is written a shift by a calculated expression
seems have been the intention, and that's also how "C" handles
that.
Why would one who intends to say: make space for three bits in
'a' to put there the bit-pattern stored in 'b'? If I'd wanted to
express that I'd use a binary '|', and because or the well known
precedence I'd have no parenthesis around, as in a << 3 | b .
Of course there's also the potential semantics that you have a
'b' that exceeds three bit and you want to have that added to the
shifted value of 'a'. But then I'd not use bit-value operations
to express that but the clear and more appropriate a * 8 + b .
Both semantics bit-op and int-arithmetic don't need parenthesis
in "C" because of its clear and sensible precedence.
You are mixing bit-ops and arithmetic unnecessarily, but you are
also too lazy to write parenthesis to clear up your dirty code?
* Why do << >> have their own level anywayAs you have been told so many times; to not require parentheses
unnecessarily, to be able to omit them and not pollute the code
with parentheses in a language that is already full of all sorts
of { } [ ] ( ) and other punctuation characters.
* Why do == != have a difference precendence from < <= >= >I've explained that already twice in the past.
Further, here: 'a * b + c' the multplication is done first, but here:You understand that '=', '*=', and '*' are three different things,
a *= b += c
It is done second.
don't you?
I hope you understand that '=' should have low precedence. And that
it makes sense to evaluate that from right to left. Do you follow?
"C" obviously decided to have them all, =, +=, *=, etc. in a single
group, and thus evaluated from right to left. - Easy rule, easy to
memorize. - And that is actually what you are demanding from many
other operators, to put them in a single group. - But here you are
complaining about it!
Of course the rules for those combined (sort of two-address) operators
could have been defined differently, in an own group with other rules.
(Algol 68 had done that, actually; the semantics are like "apply these
operations from left to right, indicating an incremental modification
of the underlying value.)
If "C" would have separated these operators from the assignment and
created another own group with different evaluation rules you'd also
have complained.
The issue I have is whether augmented assignments should return a value at all. It's just generally too confusing especially with mixed types.If you're confused about something either try to understand the rule,
or just learn it without understanding it, or look it up, a or write
your programs in a way that you understand; use parentheses, separate
complex expressions to simpler ones, etc.
It's confusing enough with assignments returning a value:If it hurts/confuses you then don't use that feature.
a = b = x;
Here, assuming x has no side-effects, you might expect this to mean the same as:I cannot tell what your brain makes you expect one semantic or another.
b = x;
a = x;
The semantics are clearly defined. Your interpretation here is wrong.
All I can suggest is what I've written above already; and to spare you
a search, it was:
If you're confused about something either try to understand the rule,
or just learn it without understanding it, or look it up, a or write
your programs in a way that you understand; use parentheses, separate
complex expressions to simpler ones, etc.
In fact it's more like: 'b = x; a = b;'. Example:And why are you composing such stupid examples (if not only for sake
double a;
float b;
a = b = 3.14159265358979323846;
Here, 'a' will be assigned the less precise 32-bit version of the RHS.
of an argument)? - An experienced programmer wouldn't write such an
expression with mixed types if he intends clear and non-dubious code.
Janis
Les messages affichés proviennent d'usenet.