Mail Archives: djgpp/1997/08/13/01:54:00
Charles Krug wrote:
>
> Victor wrote:
> >
> > Is it safe to assume that the expression
> >
> > if(first_function()==OK && second_function()==OK &&
> > third_function()==OK) return(OK);
> >
> > will be evaluated from left to right?
> No.
>
> I think that ANSI tries to demand left-to-right evalutaion of &&. But
> not all compilers do this correctly. To guarantee left-to-right
> evaluation, you need:
>
> if (first() == OK) {
> if (second() == OK) {
> if (third() == OK) {
> return (OK);
> }
> }
> }
> return (!OK);
this is an abomination to say the least. why the braces?
>
> This suggests a better (IMO) implementation that's a bit more clear:
> if (first() != OK)
> return (!OK);
> else if (second != OK)
> return (!OK);
> else if (third() != OK)
> return (!OK);
> else
> return (OK);
can you actually read this code if the blocks contain anything more
complicated than return's. even if you can, can you tell me exactly which
else belongs to which if without hesitation? also, what is the difference
between this and:
if(first() != OK)
return !OK;
if(second() != OK)
return !OK;
...
if you have a logical expression that you want to test, just test it. the
gotcha is that the evaluation of that expression stops once the value is
known so parts of the expression may not be evaluated. so if you have
code that depends on all the calls the first(), second() etc actually
being made in the if statement, you'll be in trouble.
> Don't bother trying to save mythical machine cycles by placing all your
> logicals on the same line. Remember that function calls are much more
> expensive than logicals in terms of processor time. This is especially
> true of x86 processors, which are notoriously slow in terms of stack
> performance.
readable code is much more important than whatever cycles we are talking
about 95% of the time. and to get rid of readability on the basis of a
wrong premise is, well, plain bad advice.
> The professional in me would also like to see comments explaining what
> first(), second(), and third() do, just in case you put this project
> away for a year. This is much easier to accomplish when they are on
> seperate lines.
the pro in you should read a book first.
> The best explanation of the rules of precedence I've ever heard:
>
> "Multiply and divide before you add and subtract"
> "Put parentheses around everything else"
i suggest you forget about these rules of thumb and stick with what the
language specification actually says. from the comp.lang.c faq by steve
summit:
3.4: Can I use explicit parentheses to force the order of evaluation
I want? Even if I don't, doesn't precedence dictate it?
A: Not in general.
Operator precedence and explicit parentheses impose only a
partial ordering on the evaluation of an expression. In the
expression
f() + g() * h()
although we know that the multiplication will happen before the
addition, there is no telling which of the three functions will
be called first.
When you need to ensure the order of subexpression evaluation,
you may need to use explicit temporary variables and separate
statements.
References: K&R1 Sec. 2.12 p. 49, Sec. A.7 p. 185; K&R2
Sec. 2.12 pp. 52-3, Sec. A.7 p. 200.
this is the kind of weirdness that always prompts me to say check the
comp.lang.c faq (for this question 3.4, 3.5, 3.8 would provide the
answer) and post your general c programming related questions to
comp.lang.c.moderated once you have determined that the faq does not
answer it. at least you can be reasonably certain of the quality of
responses. with a couple of exceptions, most of the responses to the
question were wrong. read the responses by Erik Max Francis and
Hans-Bernhard Broeker and avoid the rest. next time, for your own
benefit, ask your general c related questions in a newsgroup that is
dedicated to such discussions. and for all the touchy people, this was
_NOT_A_FLAME_!
-- Sinan
- Raw text -