VSCode setup

Getting started

To start with, you can clone the project separately in GitHub and open the corresponding folder or init a project from VSCode

Toolchain

Here's the list of necessary tools:

• CMake >= 3.18
• GCC or Clang compiler. There should be no problem on Linux, for development on Windows I recommend either MinGW compiler or WSL sublinux system.
• clang-format

I recommend the following VSCode extensions: C++ Extension Pack, CMake Tools, C++ TestMate, Clang-Format. If you're using WSL, corresponding WSL extension is a must.

Building the code

If everything is installed correctly, you will only need to configure a CMake build which VSCode will do automatically, you have two options: 1) using a preset 2) using a kit. Presets are the recommended way at there are project-specific build variants listed in CMakePresets.json, in case Clang/GCC are not the default C/C++ compiler you'd probably need to set it via CMakeUserPresets.json for example like this

{
    "version": 4,
    "configurePresets": [
        {
            "name": "local-benchmarks-all",
            "inherits": "benchmarks-all",
            "displayName": "Local Benchmarks MinGW",
            "generator": "MinGW Makefiles",
            "cacheVariables": {
                "CMAKE_C_COMPILER": "C:/msys64/ucrt64/bin/gcc.exe",
                "CMAKE_CXX_COMPILER": "C:/msys64/ucrt64/bin/g++.exe"
            }
        }
    ]
}

The most important things to know about CMake standard builds are:

• Debug: basic diagnostic build, can be run in something like gdb with ability to stop at any specific line on execution and inspect current state of program (variables, memory etc.)
• Release: default build for production usage, uses -O3 compile-time optimizations. Due to these optimizations usually the debug is restricted as there is no clear correspondence between lines in source code and binary produced.
• RelWithDebInfo: a diagnostic build with -O2 -g flags with slightly less optimized code then a Release build but is more clear when executed in debug mode or analyzed via profilers.

Here's additional build types that are important for the development

• AddressSanitize: compiles/links with -fsanitize=address -fno-omit-frame-pointer, this sets the target program to be very sensitive to errors with memory usage. There are other sanitizers like UB or thread but address is most important for our case.
• Coverage: builds with --coverage to later generate coverage reports, i.e. running tests and checking which source code lines were hit and which ones were not.

Testing

The project uses gtest as a testing framework, you can run for example <build_path>/unittests --help to check its capabilities. I personally recommend to use C++ TestMate plugin, it provides a simple GUI for running tests

Note that if the tests aren't shown in the Testmate panel then check that Testmate > Cpp > Test: Executables is properly set to check for test binaries.

Debugging

Usually GCC/Clang are provided with the gdb and VSCode picks it up automatically. I recommend the following configuration

  "configurations": [
      {
          "name": "C++ Debug (gdb)",
          "type": "cppdbg",
          "request": "launch",
          "program": "${workspaceFolder}/build/Debug/unittests",
          "args": [],
          "stopAtEntry": false,
          "cwd": "${workspaceFolder}",
          "environment": [],
          "externalConsole": false,
          "MIMode": "gdb",
          "setupCommands": [
              {
                  "description": "Enable pretty-printing for gdb",
                  "text": "-enable-pretty-printing",
                  "ignoreFailures": true
              }
          ],
          "miDebuggerPath": "C:\\msys64\\ucrt64\\bin\\gdb.exe" // put a proper gdb path here
      },
  ]

pretty-printing options fix the common issue with exploring C++ containers during execution breaks.