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

jthill@netcom.com (Jim Hill) writes:
> I'd say leave it [order of evaluation] unspecified ...
> and that the ordering would be better reserved
> for implicit doc.


chase@centerline.com (David Chase) wrote:
>I haven't
>seen anyone point out a benefit that any programmer actually derives
>from ambiguous order of (side-effect-containing) expression evalation
>(in practice, not in theory).
>[...]
>This [elided downside] is especially true for complicated languages like
>C++.


I can see two arguments, or perhaps just a single point viewed from two
sides, in support of the unspecified-order stipulation in C, and one more
in the presence of named parameters.


I have to point out that I did not make the efficiency argument that Mr.
Chase so thoroughly rebuts. I agree with him: that's not a good reason
now, assuming it ever was.


One thing I do like about the no-specified-order rule is that side effects
are otherwise less obvious in the source: that rule encourages the
programmer to avoid unobvious side effects. In simple code, bunching a
lot of side-effects in one statement is just bad style:


      z=f(a(),b(),c());


Suppose I want to remember the results of b(), now. Is this safe?


      brc = b();
      z=f(a(),brc,c());
      /*...*/
      if (brc) dosomething();


Or do I, following Mr. Chase's logic, have to write


      z=f(a(),(brc=b()),c());
      /*...*/
      if (brc) dosomething();


More painful possibilities in more complex situations should be obvious.


As a matter of clarity, I very much prefer having values I'm keeping
around for later use assigned as visibly as possible. Forcing
order-of-evaluation rules on parameter lists makes this at best unwieldy.


The converse argument also applies: in the same way that I want memorized
control values visible on a quick scan of the code, I also want
dependencies visible. If a(), b(), and c() are by some repugnant
circumstance common-coupled in a way that could affect behavior, I don't
*want* that fact buried. I *like* seeing things like that forced to
affect the structure of the source.


When named parameters are introduced, the additional value of e.g.
hoisting parameters introduced during maintenance to the front of the
source call that supplies non-default values, or of burying unimportant
ones, is not trivial:


      f(some,long,list,of,parameters);


could e.g. become


      f( out=>logfile, some,long,list,of,parameters);


This example, while not sufficient to demonstrate my point, does I think
suggest sufficient ones without being too complex.


The safety concern I elided (more or less that common-coupling is
unavoidable esp. in C++ and we should make it as easy as possible to write
code that doesn't break if you don't touch it) bothers me for reasons I
think my rewording makes obvious. I'm a firm believer in the "if you
misuse it or don't understand it, it should break as fast as possible"
school of design. I've more than once thought that adding a "randomize
unspecified evaluation orders" switch would be a Good Thing.


I generally refer to the results of extended maintenance on code that
relies on hidden dependencies as code piled up like cigarettes in an
ashtray nobody's emptied for too long - it's just a matter of time until
it topples into your lap in an ugly mess. The skill required to balance
the next addition without reworking or breaking the code is admirable,
yes, but the effort would imo be better spent on cleaning up the logic, to
clarify whatever confusion caused the error in the first place or to build
better support for whatever extensions are being made.


==


hbaker@netcom.com (Henry Baker) wrote in response to the same point:


>Uh... Isn't this just assembly language?? (I looked for it, but couldn't
>find the smiley anywhere...).


The answer to Henry's question has to be "Yes. So?" In what way is not
having strictly textual order-of-evaluation rules inside an argument list
any more "assembly language"-like than having them? Strict textual order
and implicit dependencies are a hallmark of assembler code. I looked for
a smiley, but...


Jim
--
Jim Hill Contents public domain and worth $.02 more than you paid.
jthill@netcom.com PGPrint: 6B 85 76 D1 EF BA 2C 78 12 25 8A 5A BF F3 37 7E
--

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