> On 05/04/07, Brian Ellis <[EMAIL PROTECTED]> wrote: > > > > Now if there were actual function calls in the initialization, and no > > records were emitted, I would consider that to be a problem (haven't tested > > this at the moment though), however, static initializers like that could > > easily be skipped as a feature in the interest of saving space. > > > > Example : > > int i = 0; > > int j = 2; > > int n = CalculateSomething( j, &i ); > > int k = 3; > > > > I would expect debug records for the initialization of 'n' to be emitted > > and a break point to properly work on that line... all others I could > > completely care less for. > > I don't really understand, because the problem remains that if you > break before int n... and do print n you get a value, whereas you > should get an error saying the variable is not in scope. > > > Heck, if the scope for k (being a primitive type that is initialized with a > > compile-time > > constant value) were started before n, i wouldn't even consider that to be > > a bug... I would > > consider it a marvel of intelligence in the compiler. > > How so? > > Rob
In theory, an intelligent compiler might be able to initialize primitives on a stack frame either using a faster bulk-copy mechanism or using a lazy assignment mechanism (actual performance gain between the 2 might differ based on source code). Although such an enhancement would be minor, it is still possible that out of order or amortization could pay off. Some might complain that reordering co-scoped primitives is out of the question (such that i, j, and k are all together with maybe a 4th primitive for a bulk initialization), but if I had to touch any code that depended on the ordering of non-struct or not explicitly scoped variables on the stack... I'd wash my hands with bleach. In fact, on some architectures, reordering commonly used variables can have a drastic impact on internal cache bus usage and cause noteworthy performance differences. As long as dependency hierarchies are honored, out of order initialization and placement are no different than out of order execution. Ensuring that this debug information is emitted might tie the hands of such optimizations. Additionally, a debugger is not an automated process. It is a tool intended to be used by an intelligent agent. At the break point before the initialization of n, I would understand if k were visible and maybe already had the value of 3. I could also understand if n were visible and had either a garbage value or (similar to Micro$hit's debug builds) had a preinitialized value of 0xCDCDCDCD. If the debugger can see a value before it's proper initialization, this is something that the user can easily ignore. ONTOH, if a line of code previous to the declaration could see the variable, then that would be a bug. - Brian ____________________________________________________________________________________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
