5 ms·

Why on earth would you want a language where { int i; if (x) return; i=2; ... } generates more opcodes and takes more CPU time to run than { if (x) return; i

• nitrogen 12y ago
  The variable i only needs to be initialized if it is accessed before being assigned, or if one wants the local stack to be cleared at every function call to avoid data leaks from previous/to later function calls. The second case explains why someone might want int i; do_something(); i = 2; to behave differently from do_something(); int i = 2;
  • xamuel 12y ago
    'Telling whether i will be accessed before being assigned' is equivalent to the halting problem. In your example, the only way the two options could differ would be if do_something() was dereferencing an invalid pointer that pointed at i. So what you really want is some kind of pointer guard, not automatic variable initialization.
    • nitrogen 12y ago
      'Telling whether i will be accessed before being assigned' is equivalent to the halting problem. Not in C it isn't, thanks to variable scope.
    • TheLoneWolfling 12y ago
      > 'Telling whether i will be accessed before being assigned' is equivalent to the halting problem. This is true. However, figuring out the most efficient program that's equivalent to a given program also suffers from the halting problem, and that's literally the definition of the goal of an optimizer. So no: in general you cannot prove if an arbitrary variable will be accessed. However, you can, and will, take a conservative approach and narrow it down as much as possible. In other words, if you can prove that it will be accessed before being assigned, great. If you can prove that it won't be accessed before being assigned, great. If you can't prove either... Meh, you have to include a redundant store. It's exactly the same way that optimizers work to, for example, remove redundant stores to a variable. Because it is. Except that, if you read carefully, what I proposed wasn't quite the same thing. I'm proposing a language where a read from an uninitialized variable must be consistent with the uninitialized variable having been set to an arbitrary value (in range) before the first read from it. So compiling the static code {int x; return x;} into {return 0;} is perfectly allowed, as is compiling it into {return 42;}.
• masklinn 12y ago
  A non-braindead compiler would trivially see that the first store has no effect and would optimise it away.
  • xamuel 12y ago
    In that silly case, sure, but in the general case that's equivalent to the halting problem.
    • amalcon 12y ago
      The compiler can just assume that any given call will halt for this purpose. Nobody is likely to care if there is an unnecessary instruction before an infinite loop. Edit: To clarify, the general strategy here is to apply the optimization if and only if the compiler can prove it valid (which will be most of the time). Personally, I prefer the strategy of having the compiler produce an error when it can't prove something is initialized, but auto-initialization only when necessary is totally possible in a huge majority of practical cases.
• TheLoneWolfling 12y ago
  I don't. That's not what I'm saying. I'm saying that I want a language where {int i; return i - i;} always returns zero, for instance.