Mail Archives: djgpp/1996/12/03/21:38:53
In article <57ve1o$rfk AT lyra DOT csx DOT cam DOT ac DOT uk>, gpt20 AT thor DOT cam DOT ac DOT uk (G.P. Tootell) writes:
>
|>i'm used to doing a=b=c=0; to set more than one variable at a time, and by error
|>i had extended this analogy to if (a==b==c==0) { do stuff }
|>no djgpp didn't throw up any errors about this even with -wall and indeed ran the
|>compiled code fine. however the interpretation of this is not what i expected.
|>instead of treating this as a==b && b==c && c==0, it treated it as a==b && c==0
|>can anyone explain this behavior? should it not have been reported as a warning?
|
Operators like && and || make sense when they are chained together.
Operators like == don't. They are pairwise: each operator needs something
on its left hand side, and something on its right. The rules of
precedence make your statement equivalent to:
((a==b) == (c==0))
or maybe it's
(((a==b)==c)==0)
or maybe even
(a==(b==(c==0)))
That is, you end up comparing two variables for equality, and then testing
the result of this (which can only yield true or false) as being equivalent
to some other variable, or some other comparison.
It's difficult to say whether such statements should lead to warnings.
If they do, one could argue EVERY statement which doesn't contain all
the brackets necessary to indicate explictly what the evaluation order
should be should cause a warning. I would find that annoying, despite the
fact that I tend to use brackets far more often than the strict rules
of precedence require, just to reassure myself that I know what's
happening.
--------------------------------------------------------------------------------
Kevin Ashley b DOT bunny AT Ulcc DOT ac DOT uk
Development Manager http://www.ulcc.ac.uk/staff/Kevin+Ashley
University of London Computer Centre. ...ukc!ncdlab!K.Ashley
This is not a signature
- Raw text -