Newsgroups: | comp.compilers |
From: | jhallen@world.std.com (Joseph H Allen) |
Keywords: | C++, optimize |
Organization: | The World Public Access UNIX, Brookline, MA |
References: | 95-07-068 95-07-113 |
Date: | Fri, 21 Jul 1995 10:22:40 GMT |
Henry Baker <hbaker@netcom.com> wrote:
>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".
One "good reason" is if/when named (as opposed to positional) parameters
ever get added to C++ (I'm having to deal with this issue now with my
language Ivy). For example:
foo(`x=7,`y=8) and foo(`y=8,`x=7) are equivalent.
So do you evaluate them in order of appearance or in the order they are
pushed on the stack (which probably depends on how the function was
defined)?
>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.
Yeah, I tend to agree. I find that it simplifies coding if I know the order
of evaluation- plus I think right-to-left should be the order of evaluation.
But it may require the compiler to allocate stack for parameters before
they are evaluated in the case where the language has named parameters.
This issue is similar to Lisp's and Scheme's various forms of let for the
ordering of local symbol allocation. More syntax could easily be added to
force various orders of evluation:
foo(parallel(x,y,leftright(z,q,parallel(a,b))))
But on the other hand, this may be a strong case of dimishing returns for
these features. You can get by without them.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.