Re: Order of argument evaluation in C++, etc.
karlcz@moraine.hip.berkeley.edu (Karl Czajkowski)
Wed, 26 Jul 1995 04:06:36 GMT
From comp.compilers
| Related articles |
|---|
|
[2 earlier articles] |
|
Re: Order of argument evaluation in C++, etc. chase@centerline.com (1995-07-12) |
|
Re: Order of argument evaluation in C++, etc. hbaker@netcom.com (1995-07-18) |
|
Re: Order of argument evaluation in C++, etc. stefan.monnier@epfl.ch (Stefan Monnier) (1995-07-20) |
|
Re: Order of argument evaluation in C++, etc. dmk@dmk.com (1995-07-21) |
|
Re: Order of argument evaluation in C++, etc. jhallen@world.std.com (1995-07-21) |
|
Re: Order of argument evaluation in C++, etc. hbaker@netcom.com (1995-07-26) |
|
Re: Order of argument evaluation in C++, etc. karlcz@moraine.hip.berkeley.edu (1995-07-26) |
|
Re: Order of argument evaluation in C++, etc. Steve_Kilbane@cegelecproj.co.uk (1995-07-26) |
|
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) |
|
[34 later articles] |
| List of all articles for this month |
| Newsgroups: | comp.compilers |
| From: | karlcz@moraine.hip.berkeley.edu (Karl Czajkowski) |
| Keywords: | C++, optimize |
| Organization: | University of California, Berkeley |
| References: | 95-07-068 95-07-132 |
| Date: | Wed, 26 Jul 1995 04:06:36 GMT |
Stefan Monnier <stefan.monnier@epfl.ch> wrote:
>
>What's wrong with using
>
> tmp1=argexp1;
> tmp2=argexp2;
> ...
> fun(tmp1, tmp2, ...)
>
>instead of
>
> fun(argexp1, argexp2, ..)
>
What about providing more than one invocation mechanism, allowing the
programmer to specify partial ordering constraints? I always thought such
"parallel" invocations would clearly specify a sort of private
barrier-syncronization, particularily when mixed with first-class
continuations, but I wouldn't want to have to manually syncronize all those
other calls...
Or perhaps a meta-object protocol to configure the invocation mechanism in a
particular lexical scope would satisfy both the sequential-thinking
programmer and the parallel architecture?
karl c.
--
Karl Czajkowski
Reply-To: karlcz@uclink.berkeley.edu
--
Post a followup to this message
Return to the
comp.compilers page.
Search the
comp.compilers archives again.