From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 19:58:38 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CAD416A4D0 for ; Fri, 28 Jan 2005 19:58:38 +0000 (GMT) Received: from Daffy.timing.com (daffy.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77C5D43D46 for ; Fri, 28 Jan 2005 19:58:37 +0000 (GMT) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@piglet.timing.com [206.168.13.178]) by Daffy.timing.com (8.12.8p2/8.12.8) with ESMTP id j0SJwaEf091772; Fri, 28 Jan 2005 12:58:36 -0700 (MST) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@localhost.timing.com [127.0.0.1]) by piglet.timing.com (8.12.6p3/8.12.6) with ESMTP id j0SJwaOx050464; Fri, 28 Jan 2005 12:58:36 -0700 (MST) (envelope-from ben@piglet.timing.com) Received: (from ben@localhost) by piglet.timing.com (8.12.6p3/8.12.6/Submit) id j0SJwZpL050461; Fri, 28 Jan 2005 12:58:35 -0700 (MST) From: Ben Mesander MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16890.39275.761277.609543@piglet.timing.com> Date: Fri, 28 Jan 2005 12:58:35 -0700 To: Peter Jeremy In-Reply-To: <20050128183611.GG32122@cirb503493.alcatel.com.au> References: <20050128173327.GI61409@myrddin.originative.co.uk> <20050128183611.GG32122@cirb503493.alcatel.com.au> X-Mailer: VM 7.00 under Emacs 21.2.95.2 X-Virus-Scanned: ClamAV 0.80/664/Thu Jan 13 08:13:05 2005 clamav-milter version 0.80j on Daffy.timing.com X-Virus-Status: Clean cc: arch@freebsd.org cc: Paul Richards Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2005 19:58:38 -0000 Peter Jeremy writes: > It is most useful for variables with a short lexical lifetime in large > functions. For a variable with a long lifetime - especially one which > is infrequently referenced - it can make it much harder to locate the > variable definition. It is also far less obvious what variable are > in scope at any point - which is an issue if you are writing some new > code and need a work variable. On the positive side, it is also very useful for allowing you to make things that shouldn't change really const. You can declare: const int foo = bar*GRONK + 37; in the middle of a block, and get a compile-time error if you try to change it later while maintaining the code. If you're forced to do all decl's at the top of a function, it's somewhat more work to be const correct. The other points you bring up are mostly big issues only if the functions in question are quite large, which some (but I'm not sure all) developers feel is indicative of other problems with the code. Regards, Ben