5 ms·

So your solution to having too many () is to have just as many {}. I'm not complaining but...

• PeterisP 3y ago
  Well, no, the above solution is to have a {} if and only if explicit scoping is desired instead of having just as many {} as there would be (). Sometimes you need explicit scope for a bunch of things and the code would benefit from it. That doesn't justify having explicit scopes for everything all the time.
  • zelphirkalt 3y ago
    Isn't is always safer to have variables scoped only to the relevant part of the code, that is supposed to make use of them? So basically it would result in almost the same number of parens.
    • lex-lightning 3y ago
      This isn’t always possible, even in lisp. Compare to Rust’s non-lexical lifetimes
      • zelphirkalt 3y ago
        I don't see how it could ever be not possible. Maybe not always convenient, but impossible? How?
        • lex-lightning 3y ago
          a = getInt(); b = getInt() + a; c = getInt(); d = b / c; puts(d); puts(c); puts(b); puts(a); Nothing in the middle of this code prevents using ‘a’ even though it isn’t relevant to ‘c’. And there’s no way to arrange it to change that.
          • zelphirkalt 3y ago
            If `c` does not depend on `a`, then the re-arrangement seems simple: Define `c` later.
            • susam 3y ago
              > If `c` does not depend on `a`, then the re-arrangement seems simple: Define `c` later. How does that prevent 'a' from being in the scope where 'c' is defined? It is not clear to me what you mean by defining 'c' later. Later where? And how do we ensure that 'a' is not accessible there? I think lex-lightning's comment has a point. We need to define 'a' and we need to define 'c' and then we need to print 'c' before printing 'a', so although 'c' does not depend on 'a', we still need to keep 'a' in scope because we cannot print it before we print 'c'. Perhaps a convoluted solution to the problem posed in lex-lightning's comment would be something like this: #include <stdio.h> int getint() { return 42; } int main() { int a = getint(); int b = getint() + a; int c; { // Shadow 'a' here to make the outer 'a' inaccessible in this scope. int *a = NULL; (void) a; c = getint(); } int d = b / c; printf("%d\n", d); printf("%d\n", c); printf("%d\n", b); printf("%d\n", a); return 0; } Output: $ cc -std=c99 -Wall -Wextra -pedantic foo.c && ./a.out 2 42 84 42
              • lex-lightning 3y ago
                I appreciate your interest. I’d argue that even declaring ‘c’ is against the spirit though. To say nothing of the eldritch shadow cast there (no disrespect, I think we’re both enjoying playing around here)
                • susam 3y ago
                  > I’d argue that even declaring ‘c’ is against the spirit though. Yes, I agree. My code example is meant to show the best we can possibly do to solve the problem in your comment and how contrived that solution is. The fact that this solution is contrived and diverges from the intended spirit of the problem only emphasizes the point of your comment. That's why I am eager to understand what zelphirkalt really meant when they wrote, "the re-arrangement seems simple: define `c` later". It seems far from simple and, in fact, impossible if we want to avoid contrived solutions.
      • xmcqdpt2 3y ago
        No it isn't. In C you often have to keep pointers around for longer than you need to so that you can free() them at the end of a block. But still, the original post said that they have to deal with this: > because I always see about 10 uninitialized variables at the start of each function, where half of those are used only once That's bad!