Re: Order of argument evaluation in C++, etc.

sethml@sloth.ugcs.caltech.edu (Seth LaForge)
Wed, 16 Aug 1995 07:07:08 GMT

          From comp.compilers

Related articles
[21 earlier articles]
Re: Order of argument evaluation in C++, etc. hbaker@netcom.com (1995-08-10)
Re: Order of argument evaluation in C++, etc. chase@centerline.com (1995-08-11)
Re: Order of argument evaluation in C++, etc. eggert@twinsun.com (1995-08-13)
Re: Order of argument evaluation in C++, etc. rfg@rahul.net (Ronald F. Guilmette) (1995-08-14)
Re: Order of argument evaluation in C++, etc. graham.matthews@pell.anu.edu.au (1995-08-16)
Re: Order of argument evaluation in C++, etc. bobduff@world.std.com (1995-08-16)
Re: Order of argument evaluation in C++, etc. sethml@sloth.ugcs.caltech.edu (1995-08-16)
Re: Order of argument evaluation in C++, etc. ok@cs.rmit.edu.au (1995-08-16)
Re: Order of argument evaluation in C++, etc. msb@sq.com (1995-08-18)
Re: Order of argument evaluation in C++, etc. ka@socrates.hr.att.com (1995-08-19)
Re: Order of argument evaluation in C++, etc. hbaker@netcom.com (1995-08-21)
Re: Order of argument evaluation in C++, etc. chase@centerline.com (1995-08-21)
Re: Order of argument evaluation in C++, etc. chase@centerline.com (1995-08-21)
[15 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: sethml@sloth.ugcs.caltech.edu (Seth LaForge)
Keywords: C++, optimize, Scheme
Organization: California Institute of Technology, Pasadena, CA
References: 95-08-034 95-08-096
Date: Wed, 16 Aug 1995 07:07:08 GMT

Paul Eggert <eggert@twinsun.com> wrote:
>In my opinion, order-of-evaluation is the most important problem
>area in the C Standard proper. Other language standards since Algol 68
>(e.g. Ada, Fortran, PL/I, Scheme) have addressed this issue more clearly.
>Future C and C++ standards should do so as well.


I don't know about the others, but the Scheme standard (The Revised ^
4 Report on the Algorithmic Language Scheme) states very clearly in
section 4.1.3 (Procedure Calls) that, as in C, evaluation order is
undefined.


I think undefined order of evaluation makes all the sense in the
world. Clearly no one order of evaluation is best; as someone's
mentioned here, some optimizers will even change the order of
evaluation within a program. I don't think it's worth constraining
optimization for dubious gain.


Also, backward compatibility is a serious problem. If anyone starts
writing code that depends on order of evaluation, then it will not be
portable to any existing compiler.


I do very much like the idea of a compiler flag to specify evaluation
order for debugging purposes. Any gcc implementors out there?


Seth
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.