in reply to Re: No braces
in thread No braces

It also doesn't create a scope, but I don't know how costly entering and leaving a scope in C is, so it might not matter.

IIRC, C89 doesn't do scope at anything less than a single function (which is why you have to declare all your variables at the top of your function). I believe C99 introduced the much tighter lexical scoping used in Perl and Java (i.e., you can declare variables inside a block and they disappear at the end of the block). Given C's almost non-existant run time environment, I would imagine that the cost is done entirely at compile time.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Re: Re: No braces
by duff (Parson) on Feb 11, 2004 at 20:03 UTC

    Nope. C has always allowed you to declare your variables immediately after the opening brace. I.e., if (a < 5) { int t; ... } is and always has been (to my knowledge) legal C.

    duff

[reply]
[d/l]
      The C language allows you to declare variables at different visibility scopes, but all of the runtime cost of that allocation is usually incurred when the function is entered and left. So the following function allocates three words at entry, and frees three words at exit. 
      void func() {
    int a, b;          // allocate 3 words for a, b, c, d
    ...
    if (b) {
       int c;          // already allocated, now visible
       ...
    }
    if (a) {
       int d;          // recycle word for c, now renamed
       ...
    }
    ...
}                      // a, b, c, d (3 words) all freed

      [download]

      C++ compilers also usually allocate the stack space when the function is entered and left also, but constructors and destructors must be executed at the marked edges of scope, unless the compiler can prove it would have no effect one way or the other.

      Allocation is a detail left to the compiler, whereas the actual rules of order of operations are defined by the language spec. Play with your "output as assembler" options to check the effects of runtime overhead.

      --
      [ e d @ h a l l e y . c c ]

[reply]
[d/l]

In Section Meditations