Maybe it's too meaningful, i.e., too ambiguous. Were it literally meaningless, would it be compilable and executable? 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. > > 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 > > > > ________________________________________________________________ Please visit a saintly hero: http://www.jakemoore.org
