Re: c99/c++ localised variable definition

From: Sam Leffler (sam_at_errno.com)
Date: 01/29/05

  • Next message: Paul Richards: "Re: c99/c++ localised variable definition" 
    Date: Sat, 29 Jan 2005 10:33:22 -0800
To: Robert Watson <rwatson@freebsd.org>

    Robert Watson wrote:
    > 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

    When variables are used only in a limited scope I find it better to
    locate it close to the code rather than some far off spot like the
    outermost block. Your example above could easily be a case like that.
    Forcing variable declarations to the top of the function means extra
    #ifdef's and makes it easy to forget if you happen to delete or alter
    the code body.

    >
    > 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.

    One thing I especially like about c++'s ability to declare variables
    mid-block in that it lets you insure variables are initialized by
    combining declaration and initialization. That is instead of

            int needed_somewhere_way_far_away;
            ...lots of code...
            needed_somewhere_way_far_away = something_not_available_at_top_of_function;

    you can combine the decl and the initialization. This is a requirement
    when you want to use const.

            Sam
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Paul Richards: "Re: c99/c++ localised variable definition"

    Relevant Pages

    • Re: Making C better (by borrowing from C++)
      ... there's no way to be certain unless declarations are restricted not ... merely to the top of the scope, but to the top of the function. ... line by line for the matching declaration; the context switch between ... the two search modes costs at least as much as the nominally more ...
      (comp.lang.c)
    • Re: Identify new pairs in an array
      ... Leaving us to figure it out for ourselves from the code? ... [declarations below rearranged into groups I can comment on] ... One-character variable names suck even more when they ... You should limit the scope of variables to the smallest possible scope. ...
      (comp.lang.perl.misc)
    • Re: About String
      ... My idea is that every statement list is a scope. ... What is so special in statement lists? ... and to me declarations intermixed with statements look similarly ... You declare something inside a loop body, ...
      (comp.lang.ada)
    • Re: Java needs "goto" (was Re: hi)
      ... declarations are collected at the start of the method, ... the whole thing and starting from scratch. ... Too much work to be done and too lil time to do it. ... Played with this scope thing in just about ...
      (comp.lang.java.programmer)
    • Re: Cant get static SolidBrush to initialize... what am I missing
      ... The order of instantiation problem is amazing given the way I have it setup. ... At the file scope I attempted to instantiate the Gdipm ... Any statements at namespace/file scope that define variables are executed ... the order of initialization across files is unspecified. ...
      (microsoft.public.vc.language)