BCS wrote: >> Interesting idea, but IMO using NaN as a default initializer is just a >> crutch for not having a real system of compile-time >> detecting/preventing of uninitialized variables from being read (C#'s >> system for this works very well in my experience). > > I think you can prove that it is impossible to do this totally correctly: > > int i; > > for(int j = foo(); j > 0; j--) i = bar(j); // what if foo() returns -5?
Complete static analysis of the flow of program control is the holy grail of compiler construction. It would allow automatic proof of many program properties (such as initialization). It may not be impossible, but it is extremely complicated. If nothing is known about the post-condition of 'foo', the sensible conclusion would be that 'i' may not be initialized after the loop. If you know that the return value of 'foo' is always positive under the given conditions, then you know otherwise. In the general case, however, you can't guarantee correct static analysis. This leaves a language/compiler with two options, I believe: * Do nothing about it. Let the programmer use int.min or set a bool to test initialization at runtime. * Add 'uninitialized' to the set of possible states of each type. Every time a variable is read, assert that it is initialized first. Use the static analysis techniques that *are* available (a set that will continue to grow) to eliminate these tests (and the extended state) where possible. The first method has the advantage of simplicity for the compiler and better runtime performance in most cases. The second method has the advantage of automatic detection of subtle bugs and more simplicity for the programmer. -- Michiel Helvensteijn
