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

Stefan Monnier <stefan.monnier@epfl.ch>
Mon, 28 Aug 1995 08:34:27 GMT

          From comp.compilers

Related articles
[40 earlier articles]
Re: Order of argument evaluation in C++, etc. way@cis.udel.edu (Thomas Way) (1995-08-23)
Re: Order of argument evaluation in C++, etc. jmccarty@spdmail.spd.dsccc.com (1995-08-24)
Re: Order of argument evaluation in C++, etc. daniels@cse.ogi.edu (1995-08-24)
Re: Order of argument evaluation in C++, etc. pardo@cs.washington.edu (1995-08-25)
Re: Order of argument evaluation in C++, etc. hbaker@netcom.com (1995-08-25)
Re: Order of argument evaluation in C++, etc. jan@neuroinformatik.ruhr-uni-bochum.de (1995-08-25)
Re: Order of argument evaluation in C++, etc. stefan.monnier@epfl.ch (Stefan Monnier) (1995-08-28)
Re: Order of argument evaluation in C++, etc. chase@centerline.com (1995-08-28)
Re: Order of argument evaluation in C++, etc. hbaker@netcom.com (1995-08-30)
| List of all articles for this month |
Newsgroups: comp.compilers
From: Stefan Monnier <stefan.monnier@epfl.ch>
Keywords: C, optimize, design
Organization: Ecole Polytechnique Federale de Lausanne
References: <95-07-068@comp.compilers 95-08-171
Date: Mon, 28 Aug 1995 08:34:27 GMT

So what's the current score ?


In favor of specifying the order:
- more precise semantics
- reproducible behavior




Against specifying the order:
- compatibility with older compilers and calling conventions
- freedom for the implementor
- parallelism




I may have missed some, but anyway:
- leaving the order unspecified allows old compilers to be considered
    compatible, but I'm not convince it's all that interesting since
    ANSI defined new features that make these old compilers
    non-compliant anyway. And the "unspecification" makes old programs
    relying on evaluation order non-compliant also, so compatibility
    doesn't seem like a good argument. And the detail about calling
    convention is not very convincing either since you can always
    evaluate in one way and push in another (or you can also "push" in
    a non-stack order). It might have some impact on register usage,
    but I'm sure clever ways exist to circumvent the problem.
- freedom for the implementor is not a good target in and of itself.
    A language is designed for users, not for implementors.
- parallelism is probably a bad excuse: just give me examples where a
    C compiler could exploit parallelism if the order is unspecified
    while it could not if the order was specified and I might be
    convinced, but I can't think of any example. (don't forget that C
    has a sequential nature, so noone expect to see effects of
    parallelism, except for speed improvements).


Stefan
--


Post a followup to this message

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