Re: Order of argument evaluation in C++, et

Marc Shepherd <shepherd@schubert.sbi.com> wrote:
>Dave Lloyd <dave@occl-cam.demon.co.uk> () writes:
>>This old chestnut keeps cropping up again and again with every new
>>language and then reiterated for all the existing languages.
>>
>>This has been resolved properly many times and promptly ignored by
>>the next language committee. Algol 68 did a very good job with
>>collateral and serial evaluation which leads to no surprises once the
>>easy fact that left precedence does not imply left ordering is
>>accepted.....
>[snip]
>
>Dave Lloyd ignores the fact that C++ already had a huge body of existing
>practice well before any "committee" ever dealt with it. And C++, of course,
>was designed to be compatible (insofaras possible) with C, which was designed
>to be compatible with B, which was designed to be compatible with BCPL, which
>predates Algol 68.
>
>I wouldn't be so fast to accuse the committee of "ignoring" anything.
>It is not in their charter to wipe the slate clean and redesign the
>language the way it would have been if we were starting from scratch
>today. (If it were, then "order of evaluation" would be merely one
>of many historical warts that would be candidates for redesign, and
>you'd end up with a brand new language, which might be extremely
>interesting, but would have nothing to do with C++.)


I think that this misstates what the C++ standardization committee could
have done fairly completely.


The commitee could have specified some strict evaluation order rules,
and doing so would not have created any incompatabilities with the
pre-existing loose rules of either C or C++. In short, if the committee
had decided to restrict evaluation order even more than the modest
amount by which evaluation order is already restricted by the C and
(draft) C++ standard, this would certainly have had the effect of
placing more limitations on what _implementors_ could do, but it would
not have rendered any pre-existing C or C++ code suddenly illegal.
Quite the contrary. If the evaluation order for expressions was more
completely specified, then many expressions which the C and/or (draft)
C++ standards would currently classify as producing undefined behavior
would instead become entirely deterministic (and entirely legal) in
their behavior and effects. In other words, the restriction of per-
missible evaluation ordering in C and/or C++ would actually have the
effect of _expanding_ the set of valid programs in these languages,
even though it would subject implementors to more extensive requirements
in this area. But as it says in the Rationale for the C standard,
``Existing code is important. Existing implementations are not.''
--


-- Ron Guilmette, Roseville, CA ----
---- E-mail: rfg@segfault.us.com ---
--

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