40078Re: Mainly noise
- Jul 6, 2005Matthew Winn wrote:
> What does p = func(++p) _mean_? You're assigning two different valuesOrder of evaluation for "=" is right to left. I expect the expression
> to p at the same time: you're trying to give p the value p+1 and the
> return value of func(). It's like saying int i = 1 = 2 and expecting
> it to do both. If you mean p = func(p+1) then say p = func(p+1): it'll
> execute faster and it's easier for readers to understand.
on the right to be evaluated before the result is assigned to the lvalue
on the left. Isn't that what everybody expects? You can't assign a
value before you know what the value is...
Another example where order of evaluation matters:
n = (getc(fd) << 8) + getc(fd);
The expression with "+" is evaluated from left to right, thus the first
read byte is shifted. This is not unusual code, right?
Adding up three byte values and putting the result in the fourth byte:
*p = *p++ + *p++ + *p++;
It's weird, but I don't think that it is unclear about what is expected
> In the case of expressions like i = ++i both assignments to i have theIf you know that evaluating the expression is done before the assignment
> same value, so it's easy to claim that it's obvious what should happen,
> but what about less obvious cases? What should
> int i = 1;
> i = ++i + ++i;
> mean? I can think of ways in which that could give any integer result
> from 2 to 6 depending on the order in which registers are allocated and
> the way values are incremented and stored. It's easy to say that the
> compiler should work out what was intended, but if humans can't decide
> what was intended how can a compiler written by humans do it?
then it's clear what should happen. But your example is unrealistic,
there is no point in doing the second increment.
Order of evaluation matters in many cases, thus it's not at all strange
to define this for the assignment. Most notably for C is:
if (p != NULL && *p == 1)
The && operator involves evaluating from left to right, and once it's
clear the result is False the evaluation stops. This is defined in the
standard, right? Otherwise a lot of code would break...
> It's poor coding practice not only because the compiler's behaviour isRight, the ++p doesn't make sense here, since the result of the
> undefined, but also because anyone reading the source has to work harder
> to determine the intention of the code. If I saw
> p = vim_strchr(++p, '/');
> I wouldn't know whether the "++p" was a mistake and should be "p+1", or
> whether the "p =" was a mistake and the value was being assigned to the
> wrong variable, or even whether the "++p" was a mistake and the wrong
> variable was being incremented. As written that code makes no sense,
> and if I can't work out what it means the compiler certainly shouldn't.
increment doesn't need to be stored. The code isn't written like that,
the increment is done in a macro. The code did make sense before
expanding the macro. The macro might be suspicious, but isn't using
Vi is clearly superior to emacs, since "vi" has only two characters
(and two keystrokes), while "emacs" has five. (Randy C. Ford)
/// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
/// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ Project leader for A-A-P -- http://www.A-A-P.org ///
\\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
- << Previous post in topic Next post in topic >>