Loading ...
Sorry, an error occurred while loading the content.

40078Re: Mainly noise

Expand Messages
  • Bram Moolenaar
    Jul 6, 2005
    • 0 Attachment
      Matthew Winn wrote:

      > What does p = func(++p) _mean_? You're assigning two different values
      > 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.

      Order of evaluation for "=" is right to left. I expect the expression
      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
      to happen.

      > In the case of expressions like i = ++i both assignments to i have the
      > 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?

      If you know that evaluating the expression is done before the assignment
      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 is
      > 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.

      Right, the ++p doesn't make sense here, since the result of the
      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
      macros anyway?

      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 ///
    • Show all 18 messages in this topic