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

40076Re: Mainly noise

Expand Messages
  • Matthew Winn
    Jul 6, 2005
    • 0 Attachment
      On Tue, Jul 05, 2005 at 06:15:19PM +0200, Bram Moolenaar wrote:
      >
      > Matthew Winn wrote:
      > > Why should either speed of execution
      > > or speed of compilation suffer just to deal with the special case where
      > > a programmer attempts to alter the same value two different ways in
      > > one expression, especially as p = func(p+1) is almost certainly more
      > > efficient than p = func(++p) anyway?
      >
      > In my opinion the "easy of use" of the language is much, much more
      > important than the easy to write a compiler for it. After all,
      > programming languages are there to form the interface between a human
      > and a computer. We can tell the computer to do whatever we want it to
      > do, that is quite a bit more difficult for humans :-).

      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.

      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?

      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.

      --
      Matthew Winn (matthew@...)
    • Show all 18 messages in this topic