-2

In Python when a crash happens, the line of code where it crashed and the error message is printed to the console window. This can be setup as well in Free Pascal using the lineinfo unit.

Is there an equivalent in C++ (Visual Studio Community)?

This (https://learn.microsoft.com/en-us/visualstudio/debugger/getting-started-with-the-debugger-cpp?view=vs-2019) does not tell me on which line the crash happened but helps me guess where it did, which I would like to save time on.

Seb0029
  • 69
  • 8
  • 5
    That "line of code" is called a debugger and call stack. – PaulMcKenzie Aug 06 '20 at 22:16
  • You couid also use other tools to help you figure out what's wrong. Here's a list of some of the available tools: https://stackoverflow.com/a/6580332/7582247 – Ted Lyngmo Aug 06 '20 at 22:18
  • A compiled and optimized C++ program is typically stripped of nearly all identifying markers, functions are reduced to an address and variables are an address or an offset from another address, and the machine instructions executed often look nothing like the source code. Think of your source code as fruit dropped into a blender and the computer is drinking the resulting smoothie through one or more straws when it runs. Pulling information like the line of code, or even the line number, is next to impossible. – user4581301 Aug 06 '20 at 22:21
  • Code compiled for debugging, on the other hand, you run in a debugger and use the debugger to determine where you are and what's going on. Visual Studio has one of the industry's best debuggers. Use it or watch your free time go down the drain. – user4581301 Aug 06 '20 at 22:23
  • [Basic Visual Studio debugger use](https://learn.microsoft.com/en-us/visualstudio/debugger/debugger-feature-tour?view=vs-2019) – user4581301 Aug 06 '20 at 22:26
  • PaulMcKenzie, Pascal compiles to machine code like C++ and yet the lineinfo unit in Pascal returns the exact line of code where the crash happened and error message along with the memory addresses, which saves me all of the debugging process as detailed in the VS documentation (breakpoints, etc.) which amounts to guess work to find that line of code. I'm disappointed C++ does not have a similar thing given it is one of the modern standard programming languages and Pascal is not. Ted Lyngmo, unforunately all these programs do not help me know on which line of my code the crash happened. – Seb0029 Aug 06 '20 at 22:30
  • @Seb0029, Everything goes to machine code eventually. People don't want to have extra stuff in their executables all the time, so compilers offer a debug vs. release toggle. It's not like you're forced one way or the other. Anyway, you're overstating the effort required to use the debugger. You run a debug build of the program in the debugger (or attach it to a running process), it crashes, and the IDE shows exactly where the program is at as well as the current call stack. It's very low effort to get that information. – chris Aug 06 '20 at 22:37
  • Those other language have extra overhead and checking added to them, whether in the runtime or runtime environment they are using. C++ does not have this. For all of those things you mentioned that you get with those other languages, you pay for it with extra overhead. Why is it that C++ is almost always chosen for low-latency programs, and not Pascal? Also I bet if a program really and truly crashed, I mean crashed hard, that line information just isn't going to be there -- all you'll get is an address that points to some assembly language statement. – PaulMcKenzie Aug 06 '20 at 22:45
  • @Seb0029 one of the guiding principles of C++ is you don't pay for what you don't use. Debugging helpers like line info and easy-to-read stack traces, have a cost. If you want helpers, you need to use the tools that provide them and ask for them by name. Most mainstream C++ development environments don't provide them, opting instead for debuggers. If you want unadorned crashdump info often you can get that from the OS and a good dev environment will have a tool that can convert the OS's dump into something human-readable. – user4581301 Aug 06 '20 at 22:46
  • [Documentation for Dump file analysis in Visual Studio](https://learn.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2019) – user4581301 Aug 06 '20 at 22:49
  • @chris, in VS I set a breakpoint before where I think the crash is happening (which line of code to set this on is educated guess work since I do not know which line is causing the crash). I then press F5 to start the debugger which runs and stop at the breakpoint. I then keep pressing F11 to step into each line of code until the program crashes. I then get absolutely no info for which line of code it crashes on. I can debug my code way faster than that by printing messages to the console, before and after where I think the crash is happening and letting the program crash rather than doing F11 – Seb0029 Aug 06 '20 at 22:53
  • Sorry @user4581301 I don't have the option to create a dump file in VS Community. – Seb0029 Aug 06 '20 at 22:58
  • 1
    *I then get absolutely no info for which line of code it crashes on.* In the bottom right-hand corner (default window layout) is a Call Stack tab. That contains everything you need to know about where the program crashed, what variables were in play, and how the program got there. Extremely handy. Correction: You have to look to the left for the variables in play. Got my debuggers mixed up. – user4581301 Aug 06 '20 at 22:59
  • @user4581301, I just found it and was about to post it! Thank you and thank you all. Sorry for my ranting, it's past midnight and I've been working since 08:30 am. – Seb0029 Aug 06 '20 at 23:03
  • Creating a dump file is often done for you by the OS. If not, [Sysinternal's](https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite) Procdump tool can help you out. – user4581301 Aug 06 '20 at 23:04
  • 1
    No worries. But back in my day 8:30 was sleeping in. And we had to walk 40 miles to work--No metric back then, sonny--through wind and rain and snow. Up hill. Both ways... – user4581301 Aug 06 '20 at 23:08
  • @Seb0029, You don't need to set a breakpoint. When the program crashes while running under the debugger with no breakpoints or other setup, it will break automatically. The IDE will pull up exactly where it breaks and the call stack (or the "Just My Code" feature VS has) will lead you to the stack frame(s) you're interested in. – chris Aug 07 '20 at 00:06

1 Answers1

0

From user4581301,

I then get absolutely no info for which line of code it crashes on. In the bottom right-hand corner (default window layout) is a Call Stack tab. That contains everything you need to know about where the program crashed, what variables were in play, and how the program got there. Extremely handy. Correction: You have to look to the left for the variables in play. Got my debuggers mixed up. – user4581301 3 mins ago

From PaulMcKenzie: That "line of code" is called a debugger and call stack. – PaulMcKenzie 49 mins ago

Thank you all

Seb0029
  • 69
  • 8