Improvements in variable visibility when debugging
-
In Visual Studio 2022 17.10 Preview 2, we’re including a small quality-of-life improvement that results in the Watch/Locals window displaying local variables correctly for any arbitrary frames in the call stack in debug builds.
Yup, there's the variable
-
In Visual Studio 2022 17.10 Preview 2, we’re including a small quality-of-life improvement that results in the Watch/Locals window displaying local variables correctly for any arbitrary frames in the call stack in debug builds.
Yup, there's the variable
What a dumb feature. Where does showing out-of-scope variables end? And what if both the called function and calling function have a variable of the same name?
-
What a dumb feature. Where does showing out-of-scope variables end? And what if both the called function and calling function have a variable of the same name?
I don't understand your rejection of this feature. In the example, y is certainly within scope when foo() is called. The problem arises because the scope determined by the return address is not correct until foo() returns. You select which set of locals to display by selecting a stack frame. If the called and calling function have identically named variables, they are in different stack frames. You'll see one when selecting one stack frame, the other when selecting the other stack frame. If this is not sufficient to keep the two apart, I guess that you will feel the same confusion when creating or modifying the code in a plain code editor, regardless of debugger features. [Edit: This was an answer to another reply that seems to have been subsequently deleted.]
Religious freedom is the freedom to say that two plus two make five.