Debugging C++ with Visual Studio Code under macOS

My favorite text editor is Visual Studio Code. I estimate that it is likely the most popular software development environment. Many major software corporations have adopted Visual Studio Code.

The naming is a bit strange because Visual Studio Code has almost nothing to do with Visual Studio, except for the fact that it comes from Microsoft. For short, we often call it ‘VS Code’ although I prefer to spell out the full name.

Visual Studio Code has an interesting architecture. Visual Studio Code is largely written in TypeScript (so basically JavaScript) on top of Electron. Electron itself is made of the Node.js runtime environment together with the Web engine Chromium. Electron provides an all-purpose approach to building desktop application using JavaScript or TypeScript.

In Electron, Node.js is itself based on the Google v8 engine for JavaScript execution. Thus, Microsoft is building both on a community-supported engine (Node.js) as well as on a stack of Google software.

What is somewhat remarkable is that even though Visual Studio Code runs on a JavaScript engine, it is generally quite fast. On my main laptop, it starts up in about 0.1s. I rarely notice any lag. It is almost always snappy, whether I use it on macOS or under Windows. Under Windows, Visual Studio Code feels faster than Visual Studio. Yet Visual Studio is written in C# and C++, languages that allow much better optimization, in principle. What makes it work is all the optimization work that went into v8, Chromium, Node.js.

Visual Studio Code also seems almost infinitely extensible. It is highly portable and it has great support for Terminals. Coupled with Microsoft copilot, you get a decent AI experience for when you need to do some vibe coding. I also love the ‘Remote SSH’ extensions which allows you to connect to a remote server by ssh and work as if it was the local machine.

When I do system programming, I usually code in C or C++ using CMake as my build system. In my opinion, CMake is a great build system. I combine it with CPM for handling my dependencies.

Microsoft makes available a useful extension for CMake users called CMake Tools. I do not have much use for it but on the rare occasions when I need to launch a debugger to do non-trivial work, it is handy.

For the most part, my debugging usage under Linux is simple:

1. Open the repository where the CMake project is. It might then ask me for the compiler, but I leave it unspecified. It seems to work fine.
2. I select the target I want to run/debug by typing F1 and selecting CMake: Set Builder Target. If I just type the name of the target (e.g., the executable file), it seems to work.
3. In the text editor, I click to the left of a line where I want the debugger to stop. You can also add conditional stops.
4. I click on the little ‘bug’ icon in the bar at the bottom of the the Visual Studio Code window.

It tends to just work.

For some projects, you want to pass CMake some configuration flags. You can just create a JSON file settings.json inside the subdirectory .vscode. The JSON file contains a JSON object, and you can just add a cmake.configureArgs with special settings, such as…

{"cmake.configureArgs": ["-DSIMDJSON_DEVELOPER_MODE=ON"]}

The settings.json has many other uses. You can set preferences for the user interface, you can exclude files from the search tool, you can configure linting and so forth. You can also check in the file settings.json with your project under version control so that everyone gets the same preferences.

Unfortunately, under macOS, my debugging experience is not as smooth. The issue likely comes from the fact that macOS defaults on LLVM instead of GCC as C and C++ compilers.

Thus under macOS, I add two non-obvious steps.

1. I install ab extension called CodeLLDB by Vadim Chugunov.
2. I create a file called launch.json inside the subdirectory .vscode:

   {"configurations": [
   {
     "name": "Launch (lldb)",
     "type": "lldb",
     "request": "launch",
     "program": "${command:cmake.launchTargetPath}",
     "stopAtEntry": false,
     "cwd": "${workspaceFolder}",
     "externalConsole": false,
   }]
   }

Everything else is then like when I am under Linux. It just tends to work.

Visual Studio Code is an instance of a tool that never does anything quite perfectly. It expects you to edit JSON files by hand. It expects you to find the right extension by yourself. The debugger environnement is fine, but you won’t write love letters about it. But the whole package of Visual Studio Code succeeds brilliantly. Everything tends to just be good enough so that you can get your work done with minimal fuss.

The web itself relies on generic technologies (HTML, CSS, JavaScript) which, though individually imperfect, form a coherent and adaptable whole. Visual Studio Code reflects this philosophy: it does not try to do everything perfectly, but it provides a platform where each developer can build their own workflow. This modularity, combined with a clean interface and an active community, explains why it has become one of my favourite tools.

Generated by RSStT. The copyright belongs to the original author.

Source