40070Re: Mainly noise
- Jul 5, 2005Bram Moolenaar did utter on 05/07/2005 15:57:
> I'm glad I don't have to do that job interview :-).Why do you say obvious? By what definition? In C, assignment is no
> Of course it's not clean programming to change a pointer twice, but in
> rare situations it happens.
> It's obvious to me that the assignment always happens after evaluating
> the expression on the RHS.
different to any other operator in an expression, which is why = is
called the assigment operator. Assignment is not a statement like in
BASIC, Pascal, or Python, which is why you can do assignments within if,
while, etc. expressions. Being an expression, the order of evaluation
of the left and right hand sides of the assignment operator can be done
in any order as per any other operator's operands. All that the
standard specifies is that all side effects are resolved by the next
sequence point, nothing is said about the order of resolution between
> No optimizer should ignore the side effectsIn C the term "side effect" has a defined meaning, which is essentially
> evaluating the expression might have.
modification of the execution state, i.e. the values of variables in
registers and memory. So the simple expression i = 1; contains "side
effects" due to setting the variable i to the value 1. "Side effects"
does not mean additional changes to the ones intended as possibly
understood with the ++/-- operators.
> Also keep in mind that the "++p"Indeed, and another typical C interview question where an argument to a
> could be in a preprocessor macro and be unnoticable for the programmer
> (esp. if someone changes the header file after you wrote the code!).
macro is something like "p++" and the argument appears twice in the body
of the macro leading to undefined behaviour (the increment may happen
once or twice). Such macros should be written function like and macro
args assigned to block local variables to ensure the argument is
evaluated only once.
> If the optimizer breaks this I would say the optimizer is broken. If IThe benefit of C's approach is that the optimizer is simpler and
> have to read the details of the C standard to find something isn't
> guaranteed to work, while the code looks fine to the average programmer,
> then the C standard is broken, it doesn't do what "should happen".
therefore less bug prone. It is also more flexible across many
processor architectures providing efficient operation (smaller faster
binaries). Remember that C is used with more embedded processors than
PCs where saving bytes and cycles multiplies into big money quickly.
Some might say that a lot of the issues with copmuters is because
average programmers don't actually understand the tools they use. And C
is one of the simpler programming languages out there.
> Fortunately most compiler builders know this and define the undefinedI think you more mean that the few compilers on a couple of processor
> behavior in the way most programmers expect it to work.
architectures you are aware of happen to work in the way the code was
intended to work. I haven't seen different compilers for the same
processor behave differently, but I have seen the issue appear when
porting to other processors. Don't underestimate the benefit of jobs
running 10% faster due to optimisations possible from this flexibility in C.
Ok, this has gone way off topic. Normal service (and lurking) will be
The decision is maybe and that's final.
- << Previous post in topic Next post in topic >>