On Thu, 17 Dec 2009, Brian Budge wrote:
If multiple increment and decrement operators (++ --) are used in the
same statement, it's undefined which ones happen first. Therefore:
int a = 0;
cout << a++ << a++ << endl;
could produce 0 1 or it could produce 1 0. It would be very bad to
rely on any specific compiler behavior as this would be extremely
fragile code. The only guarantee is that the variable is modified
before or after the usage.
It's worse than that - it could produce 0 42, or 3.14 555, or "you lose",
or nothing at all. A compiler can do whatever it wants with such code and
still conform to the language. See also:
http://en.wikipedia.org/wiki/Undefined_behavior
Because it's undefined what should happen, it could be considered meaningless.
Brian
On Thu, Dec 17, 2009 at 11:52 AM, Bill McEnaney <bill@xxxxxxxxxxxx> wrote:
Where's the meaningless(?) code?
On Thu, 2009-12-17 at 10:40 -0700, Joel Dice wrote:
On Thu, 17 Dec 2009, Bob Plantz wrote:
I have seen many, many examples, both in industry and in academia,
where
programmers write tricky code claiming it is more efficient. I
claim (a)
efficiency is seldom an issue, and (b) looking at the generated
assembly
language almost always shows it is not more efficient.
I believe that the best code is that which (a) correctly solves the
problem, and (b) is the most simple-minded in appearance.
Perhaps, but the code in question here is not merely obscure - it's
simply
meaningless. I think it's a mistake to put such code in the same
category
as e.g. an affine transform implemented in inline assembly which has
well-defined meaning. The latter may pose a challenge for a
maintenance
programmer, but at least it will yield to persistence. In contrast,
undefined code is no better than a "todo" comment - you're only
option is
to replace it completely with something well-defined based on the
documentation and/or context.
I agree that there are situations where obscure code is the best,
perhaps the only, way to solve the problem. For example, in 1984 I had a
consulting job where one of my assignments was to write a logarithm
function for an embedded MC68000 environment. The only way I could get
the required speed and accuracy was to use double-precision integer
arithmetic. I wrote it in assembly language and used several "magic
numbers" to keep intermediate values in range while maximizing
arithmetic significance. My comments took more space in the listing than
the actual code. To their credit, the programming team asked for even
more documentation during my walk-through of my code.
These situations are uncommon -- and lots of fun to solve!
The most common uses of obscure code that I've seen are programmers
showing off their "understanding" of the language being used. I believe
that a good programmer does not ask what his/her code does, but rather
explains it -- either through simple, easy-to-read code, or with
thorough commenting. I use the term "good" to mean relative to the
programmer's skill level.
--Bob
________________________________________________________________
Please visit a saintly hero:
http://www.jakemoore.org
