From owner-freebsd-arch@FreeBSD.ORG Sat Jan 29 18:05:28 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 3E56C16A4D9 for ; Sat, 29 Jan 2005 18:05:28 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAA2D43D46 for ; Sat, 29 Jan 2005 18:05:27 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 8AEDB46B20; Sat, 29 Jan 2005 13:05:27 -0500 (EST) Date: Sat, 29 Jan 2005 18:04:52 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Garance A Drosihn In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Sat, 29 Jan 2005 18:05:28 -0000 On Fri, 28 Jan 2005, Garance A Drosihn wrote: > At 5:33 PM +0000 1/28/05, Paul Richards wrote: > > > >People used to programming in C++ or Perl (and many others) are > >used to defining variables as near to use as possible. This has > >never been possible before in C, but now with c99 it is. > > Well, you could get a similar effect by creating a new scope. And, FWIW, I've been hoping we could eliminate some use of "new scopes" in the current code, since they're typically used to hide the fact that excessive code is ifdef'd, or that a function should really be two functions. For example, you used to find a moderate amount (and still find some) in places like ip_input(), where people would arbitrarily add a block of code conditional on a semi-obscure kernel option, and then realize they needed variables and make it into a code block. Where it does occur, it's almost always a sign of a problem with the code structure. Here's the sort of thing I mean: int function(void) { /* lots of code */ #ifdef BASICALLY_UNUSED_BY_MOST_PEOPLE { struct foo *foo; int x; stuff(foo, x); } #endif One of the main situations in which I've found the declaration of variables close to their use helpful, as opposed to at the head of the function, is for temporary values relating to list or array iteration as part of a for loop. I.e., for (int i = 0; i < 100; i)) { } In this scenario, the re-use of i as part of a broader scope actually makes C warnings less useful, since you lose the benefit of stuff like "used but not initialized" warnings as the variables are reused. Maybe what we should be doing is identifying a couple of places where we are willing to take this approach, and it offers a clear benefit, and specifically pointing at those. I have to say that the type of coding style that annoys me somewhat to read in blended C/C++ code is this sort of thing: struct big foo; // ... large block of code struct another_big bar; // ... large block of code In environments with constrained stacks, especially in the kernel or threaded applications, having all the serious declarations up front makes it much easier to decide if things are getting out of hand. That's one reason why things like ancillary counter variables seem reasonable, but more extensive use can be problematic. Robert N M Watson