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

chase@centerline.com (David Chase) wrote:
> Having worked with C++ since 1990, and having been surprised multiple
> times by that twisted language, I'd cheerfully entertain a "results
> as if evaluated in this well-defined order" rule, along with a
> well-defined set of rules for temporary creation (or not).
>
> Why?


> You would think, given recent moves to introduce somewhat more order
> and process to software production (e.g., ISO 9000) that people would
> care more about the specification and quality of the tools that they
> use, but perhaps people haven't made that connection yet.


Since I started this thread, I have received many responses of the sort
"well, my program _depends_ upon some sort of rational ordering by the
compiler, and I haven't had any trouble yet (fingers crossed)", and from
compiler people "well, I can't think of any good reasons for this freedom
right now, but I'd like to keep my options open".


My personal feeling is that I agree (in this instance) with David Chase
100%, and would go so far as to say that far from allowing _speedups_, the
current ambiguity in the language standards actually _guarantees_ slowdowns in
programs which aspire to any amount of portability. The problem is that if you
were truly paranoid, you would have to start locking and unlocking serially
accessed data structures on the different arguments to a multi-argument
procedure.


Thus, if you were computing f(g(x),h(x)), the compiler is currently free
to _interlace_ the steps of computing g(x) with those of h(x) in any arbitrary
order, which will cause great mischief if g(x) and h(x) are accessing some
shared resource. This kind of thing puts dinner on the table for language
lawyers, but only at the expense of everyone else.


If someone really wants to evaluate g(x) and h(x) in _parallel_, I suggest
that there be some additional annotation to allow this sort of thing. For
the rest of the time, I think that the vast majority of C++ programmers would
sleep much better if the order of evaluation were nailed down as some depth
first ordering of the expression, thus allowing a simple LIFO allocation of
the (caller's) temporaries.


[Yes, I know this is ironic for me to be saying this. I'm a fan of
functional programming, too, but since making C++ into a functional
programming language is already a hopelessly lost cause, let's not
make things worse by continuing to promote confusion.]


--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
--

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