Home/ Questions/Q 8359815
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T11:16:17+00:00

While debugging some C++ code using Visual Studio 2012 RC, I noticed a strange

  • 0

While debugging some C++ code using Visual Studio 2012 RC, I noticed a strange behavior with break points on class member functions and values of member variables.

When I set the break point on a class member function, VS 2012 puts the break point on the function curly bracket. Now, when hovering over a member variable used by the function, the value is always “uninitialized”. However, pressing F10 to step to next line (first line in the function), the member variable is now changed to the correct value.

This looks like that values of member variables of a class is not loaded until stepping into the first line in the member function. But this is very confusing – what would be the point of breaking on the curly bracket then? (As is the default when setting break points on functions.)

Breaking on class member function:

Breaking on bracket

Member variable active is said to be true (which it really is not!)

Stepping to next line with F10:

enter image description here

Member variable active is now said to be false (which is correct.)

Am I missing something here or is this an actual bug in Visual Studio 2012 RC?

Edit: I found my copy of Visual Studio 2010 and tried this out. The behavior in regards to break points is the same. The difference lies in how IntelliSense handles the situation. In VS 2010, IntelliSense does not popup a tooltip at all when breaking on the curly brace, and in VS 2012 the tooltip is always displayed. I think the VS 2010 behavior is a lot better to avoid confusion.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    By setting the breakpoint on the curly brace, you are giving the debugger a choice between a rock and a hard place. One hard place is the coding style convention, do you like K&R bracing?

    void foo() {
   // etc..
}

    How do you set a breakpoint on that one? The debugger errs on the safe side, it sets a breakpoint on the function entry point. When your breakpoint hits, you can use Debug + Windows + Assembly and you’ll find out that it set the breakpoint on the very first machine code instruction in the function. Almost always push ebp. Which actually is a bit different from the normal way that the debugger tries to deal with ambiguous breakpoints, it usually looks ahead, not backwards. So this was done very much intentionally. Something that got addressed in the debugger for managed code, is is not just line-based but pays attention to the column as well. That didn’t flow back to the C++ debugger, it is still line-based.

    So inspecting local variables isn’t going to work out well, there aren’t any. Not until the function prologue gets executed that sets up the stack frame. Including this.

    The possible reason that the debugger looks backwards instead of forwards like it normally does is that you want to single-step through the constructors of class objects that are local variables. Again, not something you can set a clear breakpoint on, other than rewinding the stack yourself and set a breakpoint on the constructor. Who knows where.

    Feature, not a bug. The obvious workaround is to set a breakpoint on the first statement in the function body. Everything is setup by then, stack frame as well as local variables.

    • 0