From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3172 invoked by alias); 17 Dec 2009 20:22:30 -0000 Received: (qmail 3159 invoked by uid 22791); 17 Dec 2009 20:22:29 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-yx0-f195.google.com (HELO mail-yx0-f195.google.com) (209.85.210.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Dec 2009 20:22:24 +0000 Received: by yxe33 with SMTP id 33so4215332yxe.0 for ; Thu, 17 Dec 2009 12:22:23 -0800 (PST) Received: by 10.101.133.35 with SMTP id k35mr184816ann.24.1261081343054; Thu, 17 Dec 2009 12:22:23 -0800 (PST) Received: from jdpc-core1.ecovate.com (204-133-153-190.dia.static.qwest.net [204.133.153.190]) by mx.google.com with ESMTPS id 22sm855854ywh.45.2009.12.17.12.22.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 12:22:21 -0800 (PST) Date: Thu, 17 Dec 2009 20:28:00 -0000 From: Joel Dice To: Brian Budge cc: Bill McEnaney , Bob Plantz , Joel Dice , "W.H. Kalpa Pathum" , gcc-help Subject: Re: Could you please explain this code segment In-Reply-To: <5b7094580912171211n2f24517nf7db12888e880ff5@mail.gmail.com> Message-ID: References: <20091217195259.17C147180B@saratoga.rkirkpat.net> <5b7094580912171211n2f24517nf7db12888e880ff5@mail.gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463804110-2021271088-1261081341=:30036" X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2009-12/txt/msg00264.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463804110-2021271088-1261081341=:30036 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-length: 3426 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 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 >> > ---1463804110-2021271088-1261081341=:30036--