How to step directly into my std::function in debugger? RRS feed

  • Question

  • Is there a way to get the debugger to step directly into my std::function without having to step into all the std library code?

    I have code like this:

    If I'm sitting on the breakpoint line:  "f()"  and I do "Step Into", it steps into a bunch of std library code and I have to keep doing Step Into many times before eventually stepping into the implementation of my function.

    I thought I could use the StepOver registry key and write a NoStepInto line that prevents this by adding a registry key like this


    But instead it just completely steps over the entire call (which I guess is as expected, but not what I want).  What I want is to find a way to step into the std library functions, but keep stepping in automatically until I get to MY function (called display() in my example.)

    There's a lot of junk to go through and I'm getting seriously tired of stepping into all these functions.

    std::tr1::_Callable_fun<void (__cdecl*const)(void),0>::_ApplyX<void>()  Line 7 + 0xe bytes
    std::tr1::_Impl_no_alloc0<std::tr1::_Callable_fun<void (__cdecl*const)(void),0>,void>::_Do_call()  Line 66
    std::tr1::_Function_impl0<void>::operator()()  Line 154 + 0x17 bytes

    Keep in mind this is native (unmanaged) C++.  This happens to be VS 2010, but I'd be interested if there's a 2012 solution as well.

    Thursday, June 13, 2013 2:58 PM


All replies

  • As far as I know the answer is no.  Similar issues exist when you want to step into a function but want to avoid 5-6 constructor calls that may be part of setting up the parameters to the function.

    Ultimately, if I know where the code execution is going to go to, I will put my cursor in the target function and select run to cursor.  If I don't know where execution is going to go, then I am pretty much stuck debugging through standard library layers (and there sure seems to be a lot in std::function)

    Thursday, June 13, 2013 3:25 PM
  • @SimonRev, well with my std::function variables it is almost always the case that I don't know where the execution is going to go.  

    I also see it as being vastly different from the constructor calls that set up parameters, because the step into specific feature resolves that particular problem.  (Right click on the line of source and choose Step Into Specific, and the popup will show you an option to go directly to the function call and skip over all the parameter constructors.)  Maybe that will help you out in your situation. :)

    I'd still like to know if it's possible to innovate a workaround to this problem.

    Thursday, June 13, 2013 3:36 PM
  • Hi,

    Welcome here.

    Your issue may not have a solid answer. Please try to open a feedback at: http://visualstudio.uservoice.com/forums/121579-visual-studio

    Have a nice day.


    Elegentin Xie
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Wyck Friday, June 14, 2013 12:50 PM
    Friday, June 14, 2013 8:05 AM
  • FYI, you can now vote in support of this feature request (and others) at the Visual Studio user voice site.

    As per Elegentin Xie's advice, here is the suggestion:


    • Marked as answer by Elegentin Xie Thursday, June 27, 2013 3:46 AM
    Wednesday, June 26, 2013 4:31 PM
  • So why not just use plain old function pointers, if this is native code anyway?

    -- pa

    There  are  so  many  excellent  reasons.

    Thursday, June 27, 2013 12:23 PM
  • One possible workaround is to find where it will call your code in the std library and put a breakpoint there.  That way, when your function is called, it'll break just before execution.  Yeah, not optimal, but the best you can do for now it would seem, even 3 years later.

    I do have an AHK script which allows me to traverse the stack faster however.

    stop(comp, last, ByRef failedByEnd)
      local index
      for index, val in comp
        ;if (InStr(Clipboard, "`t" . val, true, 2))
        if (RegExMatch(Clipboard, "A)`t" . val, "", 2))
          if (Clipboard = last)
            return true
          return false
      return true
    traverse(goUp, useExclusions)
      static ignoreDlls := [ "\s*?\[External Code\]", "mfc", "msvcr", "user32"
        , "ntdll", "kernel32", "msvcr120d"
        , "[^!]*!std::", "jscript.dll!" ]
      if (goUp)
      SendPlay !7
      Sleep 200
      CoordMode, Mouse, Screen
      MouseGetPos, mouseX, mouseY
        Sleep 10
        SendPlay %directionKey%^{Insert}
        if (!useExclusions or stop(ignoreDlls, last, failedByEnd))
      if (failedByEnd)
        if (goUp)
          SendPlay {Down %count%}
          SendPlay {Up %count%}
      Sleep 100
      SendPlay {Enter}
      MouseMove, mouseX, mouseY
    ; go up stack while debugging, use exclusions
      traverse(true, true)
    ; go up stack while debugging
      traverse(true, false)
    ; go down stack while debugging
     traverse(false, false)
    ; go down stack while debugging, use exclusions
      traverse(false, true)
    ; go to top of stack
     SendPlay !7
     Sleep 200
     SendPlay {Home}{Enter}
    ; Go to currently pointed at stack frame
    #z:: SendPlay !7{Enter}

    This creates the following mappings when Visual Studio's main window is active in a debugging context:

    Win-Home or MouseMiddleButton - Go to top of stack

    Win-PageUp or MouseWheelRightButton - Go up one stack frame

    Win-Alt-PageUp or Alt-MouseWheelRightButton - Go up to next non-excluded stack frame.

    Win-Alt-PageDown or Alt-MouseWheelLeftButton - Go down to next non-excluded stack frame.

    Win-PageDown or MouseWheelLeftButton - Go down one stack frame

    Win-Z - Go to currently pointed at stack frame.

    You would use Win-Z if you leave the area and you want to get back to that stack frame you were looking at.  Note that if you go up/down the stack using this or by double clicking on any of the stack frames, you then continue execution and hit a breakpoint, if the stack frame number that you were at still exists, moving up/down the stack frames with these will move relative to your previously looked at stack frame, not from the top of the frame.  Win-Z will also get you to this frame.

    If you want to add new items or remove an item to ignore while traversing non-excluded stack frame items, then modify the ignoreDlls variable.  These are regexs.  If you want to break a long line to shorter ones, you have to lead the next line with a comma as shown.

    You will also need AHK which you can dl here.

    Occasionally, this will modify a document by adding a CR.  IIRC, this is caused by the use of SendPlay occasionally missing the target window when dealing with VS.  You might be able to stop it from happening by changing them to Send, but I couldn't use this script over Remote desktop for some reason when I did that.

    I find that this at least helps traverse only the stack frames I'm interested in.



    I don't mind someone marking a post as "Proposed as answer", but DO NOT mark it as "Answered". If I am the OP, I will decide if a post actually answers my post or not. Thank you.

    Tuesday, July 12, 2016 4:33 PM