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

graham.matthews@pell.anu.edu.au
Tue, 8 Aug 1995 11:04:36 GMT

          From comp.compilers

Related articles
[10 earlier articles]
Re: Order of argument evaluation in C++, etc. chase@centerline.com (1995-07-28)
Re: Order of argument evaluation in C++, etc. davids@ICSI.Berkeley.EDU (1995-07-30)
Re: Order of argument evaluation in C++, etc. dave@occl-cam.demon.co.uk (Dave Lloyd) (1995-07-31)
Re: Order of argument evaluation in C++, etc. jthill@netcom.com (1995-08-03)
Re: Order of argument evaluation in C++, etc. chase@centerline.com (1995-08-07)
Re: Order of argument evaluation in C++, etc. hbaker@netcom.com (1995-08-08)
Re: Order of argument evaluation in C++, etc. graham.matthews@pell.anu.edu.au (1995-08-08)
Re: Order of argument evaluation in C++, etc. det@sw.stratus.com (David Toland) (1995-08-08)
Re: Order of argument evaluation in C++, etc. jthill@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. mfinney@inmind.com (1995-08-10)
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)
[26 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: graham.matthews@pell.anu.edu.au
Keywords: design, optimize, parallel
Organization: Australian National University
References: 95-07-068 95-08-067
Date: Tue, 8 Aug 1995 11:04:36 GMT

chase@centerline.com (David Chase) writes:
>Perhaps I, too, have become a crank on this subject, but I haven't
>seen anyone point out a benefit that any programmer actually derives
>from ambiguous order of (side-effect-containing) expression evalation
>(in practice, not in theory). Over the years, people have claimed
>that this permits generation of more efficient code.


Time to add a note of "futureness" to the debate. All this argument
about order of evaluation, the disadvantages, advantage etc is all
very uniprocessor based. As soon was we start writing large scale
software for parallel machines all these little C quirks will very
quickly become impediments both to writing robust code, and to
optimisation. On a parallel processor side effects in expressions
are optimisation impediments since they force an order other than
the efficiency dataflow order. Likewise side effects in expressions
can create non-deterministic (and therefore non debuggable) code,
if you don't specify a precise order of evaluation (and hence
again forgoe the optimal dataflow order).


graham
--


Post a followup to this message

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