40069Re: Mainly noise
- Jul 5, 2005Matthew Winn wrote:
> On Tue, Jul 05, 2005 at 11:29:51AM +0200, Bram Moolenaar wrote:Well, the compiler can see whether the resulting value of p is used or
> > 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.
not, thus it can figure out what to do.
> Why should either speed of executionIn my opinion the "easy of use" of the language is much, much more
> 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?
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 ///
- << Previous post in topic Next post in topic >>