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

At the risk of sounding a bit naive in this whole debate
over order of evaluation, I have two points:


1) Perhaps if the order of evaluation of expressions whose
        results are passed as arguments is so important, these
        expressions should be evaluated prior to the actual
        fuction call. The itsy-bitsy teenie-tiny additional
        move or store/load operation is surely trivial. You are
        not talking orders of magnitude here, merely a slightly
        larger O(n) in additional overhead. Surely that is worth
        eliminating the needless fretting and worrying over`
        whether or not things are being evaluated in the order
        you hope they are.


2) In my opinion, it makes code difficult to read and support
        when function calls contain all sorts of expressions that
        are evaluated. Single statements tend to span lines more
        than necessary, and this alone slows down the task of
        digging through a year or two later to improve or otherwise
        rework pre-existing code... Particularly if it is not your
        own handiwork.


Hope this adds something to the debate.


-Tom Way
way@asel.udel.edu


[... some remnants ... heavily snipped ...]
In article 95-08-146,
David Chase <chase@centerline.com> wrote:
>ka@socrates.hr.att.com (Kenneth Almquist) writes:
>> I'm surprises that David Chase isn't familiar with compilers which
>> take advantage of the permission to evaluate arguments in arbitrary
>> order in order to generate better code. The basic idea is [Sethi-Ullman
>> numbering].
>> ... This idea is not new; the first two compilers for C (the Ritchie
>> compiler and PCC) both used it [or something similar].
>> So in the absence of register windows (which seem to have fallen out
>> of favor) requiring left-to-right evaluation will force a compiler


>Sadly enough, no compiler that I know of actually generates "optimal"
>code, for a variety of reasons (*). This one little frob is unlikely
>to make a difference that anyone would usually notice (though I, too,
>lack measurements to back this up), and if it did, those users who
>care would detect it when they profile their code (if they don't
>profile, they don't really care) and fix the order of evaluation
>manually. Therefore, all that is really lost is the automatic
>application of this apparently-minor optimization, and what is gained
>is portable, reproducible behavior.


--

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