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

40069Re: Mainly noise

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

      > On Tue, Jul 05, 2005 at 11:29:51AM +0200, Bram Moolenaar wrote:
      > >
      > > James Widman wrote:
      > >
      > > > Anyway: (i = ++i) seems, at first glance, like a safe (albeit
      > > > questionable) expression. One might think (as I did) that,
      > > > regardless of which side of '=' is evaluated first, the result is
      > > > the same. But ISO C99, section 6.5,p2 says:
      > > >
      > > > "Between the previous and next sequence point an object shall have
      > > > its stored value modified at most once by the evaluation of an
      > > > expression."
      > > >
      > > > So according to C99, (p = vim_strchr(++p, '/')) results in undefined
      > > > behavior because p is modified twice.
      > > >
      > > > ISO C++ has basically the same verbiage. I don't have our copies of
      > > > ISO C90 or the first-edition K&R C book nearby, so I don't yet know
      > > > the situation there.
      > >
      > > The problem here is the standard. C99 is probably the worst C standard
      > > that was ever made. It was clearly formed by politicians, not by
      > > practical programmers. OK, well, that's just my opinion (a ran into a
      > > couple of annoying problems).
      > >
      > > That "undefined behavior" is stupid. Of course every good-old C
      > > programmer can predict what should and will happen. Only very bad C
      > > compilers would not be able to deal with it. The standard should be
      > > adjusted to meet what programmers do and expect, not the other way
      > > around.
      >
      > It's undefined so the compiler can do it as efficiently as possible.
      > On an architecture where transferring information from the stack to
      > memory is fast, an expression like q = func(++p) may be fastest if the
      > incremented value of p isn't written back to the correct memory location
      > until after q has been altered.

      Well, the compiler can see whether the resulting value of p is used or
      not, thus it can figure out what to do.

      > 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 :-).

      It's possible for the compiler (or optimizer) to see the side effect and
      act accordingly. If there is no side effect, then use the optimal
      implementation for speed. If there is a side effect then make sure it
      works as the programmer expects.

      This does make the compiler (optimizer) a bit more complex, but that's
      an order of magnitude less important than having the teach the human to
      avoid this construct. It's something you solve once and enjoy forever.

      --
      hundred-and-one symptoms of being an internet addict:
      246. You use up your free 100 hours in less than a week.

      /// 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