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) |
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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.