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@rkirkpat.net> 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
>>
>