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

>[get the compiler to warn of frail code]


This would be nice, but it's impractical -- many functions/operators
are called for effect, and the problem arises when they're
unwittingly common-coupled. Detecting only the unwanted cases
(traces, for instance, are intentional and common) is right out, and
I'm with Henry on "holier-than-thou" style enforcement: style is
beyond the proper scope of compilers or languages.


But this isn't style. The "is this change safe" question is about as
technical and crucial as it gets, and the no-specified-order rule
limits the necessary spelunking to the current function.


Or, I should say, it goes as far as possible towards that end.
Unless I'm very much mistaken, alias identification is an insoluble
problem, and flagging order dependencies in expressions runs straight
into that wall.


To digress for a paragraph, I'm all for better tools to tag possible
problems, but I don't know of any commercial compiler that gets even
the simplest cases. When I stop to wonder why, my usual excuse is
that noone's really interested in tackling an ultimately insoluble
problem -- noone wants to take the heat from angry idiots bitching
that the compiler wasn't good enough to detect their particular
marginally-too-subtle bug, so noone even starts down that road. I
grumble, but I can't say I blame anyone.


It seems to me that a strictly-specified evaluation order in
expressions is unnecessary and limiting. Unnecessary, because we
already have ways of enforcing a particular order. Limiting, because
"it just doesn't matter" is the usual case in currently unspecified
situations, and reorganizing code is a common task: we'd soon want
some other and necessarily more cumbersome way to flag arbitrary
orderings.


And it's no safer. We'll always write code to the limits of our
comprehension, and providing alternate, subtler ways to express a
simple concept like sequencing strikes me as pointless.


Either choice is dangerous. Either way, we have subtle dependencies
to deal with. One way, we choose to force both the compiler and
programmer to assume that every choice of textual sequence matters;
the other, the programmer has to massage the code sometimes when it
really does matter. Detecting bugs won't get any easier either way.


Really, I don't think it matters a whole hell of a lot. There's a lot of
experience and judgement involved; I think everyone here has a pretty good
track record on both when it comes to code.


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.