C/C++/Objective-C

C/C++/Objective-C analysis is available as part of Developer Edition and above.

C/C++/Objective-C analysis is officially registered as CWE Compatible.

Supported Compilers, Language Standards and Operating Systems

  • Any version of Clang, GCC and Microsoft C/C++ compilers
  • Any version of Intel compiler for Linux and macOS
  • ARM5 and ARM6 compilers
  • IAR compiler for ARM, Renesas RL78, Renesas RX, Renesas V850, Texas Instruments MSP430 and for 8051
  • Compilers based wholly on GCC including for instance Linaro GCC and WindRiver GCC are also supported
  • C89, C99, C11, C++03, C++11, C++14 and C++17 standards
  • GNU extensions
  • Microsoft Windows, Linux and macOS for runtime environment

Language-Specific Properties

Discover and update the C/C++/Objective-C specific properties in: Administration > General Settings > C / C++ / Objective-C

Prerequisites

Build Wrapper

Analysis of C/C++/Objective-C projects requires the Build Wrapper. It runs the build and gathers all the configuration required for correct analysis of C/C++/Objective-C projects (such as macro definitions, include directories, …). The Build Wrapper does not impact your build; it merely eavesdrops on it and writes what it learns into files in a directory you specify.

You can download the Build Wrapper directly from your SonarQube server, so that its version perfectly matches your version of the plugin.

  • Download Build Wrapper for Linux from {SonarQube URL}/static/cpp/build-wrapper-linux-x86.zip
  • Download Build Wrapper for macOS from {SonarQube URL}/static/cpp/build-wrapper-macosx-x86.zip
  • Download Build Wrapper for Windows from {SonarQube URL}/static/cpp/build-wrapper-win-x86.zip

Unzip the downloaded Build Wrapper and configure it in your PATH because doing so is just more convenient.

SonarScanner

Analysis of C/C++/Objective-C projects requires the SonarScanner CLI.

Analysis Steps

  • When not using msbuild, it is recommended to gather all your code tree in a subdirectory of your project to avoid analysing irrelevant source files like compilation tests. You can specify such a subdirectory by setting the property sonar.sources accordingly. In the following, we assume that this subdirectory is named src.
  • Add execution of the Build Wrapper as a prefix to your usual build command (the examples below use make, xcodebuild and MSBuild, but any build tool that performs a full build can be used)

    // example for linux
    build-wrapper-linux-x86-64 --out-dir build_wrapper_output_directory make clean all
    // example for macOS
    build-wrapper-macosx-x86 --out-dir build_wrapper_output_directory xcodebuild clean build
    // example for Windows
    build-wrapper-win-x86-64.exe --out-dir  build_wrapper_output_directory MSBuild.exe /t:Rebuild
    

    Note: your build might be a long and heavy process. There is no need to run it twice. Just make one build and wrap-it up.

  • In the sonar-project.properties file at the root of your project add the property sonar.cfamily.build-wrapper-output with the path to the Build Wrapper output directory relative to the project directory (build_wrapper_output_directory in these examples)

    Sample sonar-project.properties:

    sonar.projectKey=myFirstProject
    sonar.projectName=My First C++ Project
    sonar.projectVersion=1.0
    sonar.sources=src
    sonar.cfamily.build-wrapper-output=build_wrapper_output_directory
    sonar.sourceEncoding=UTF-8
    
  • Execute the SonarScanner (sonar-scanner) from the root directory of the project

    sonar-scanner
    
  • Follow the link provided at the end of the analysis to browse your project's quality metrics in the UI

NB: The Build Wrapper collects information about the build including absolute file paths (source files, standard headers, libraries, etc...). Later on, SonarScanner uses this information and needs to access those paths. Whereas this is straightforward while running these 2 steps on the same host, it is worth some consideration when using any sort of containerization like Docker.

Analysis cache

The plugin is able to cache results of analysis and reuse them during another analysis. This has the benefit to speed-up subsequent analysis by analyzing only things that changed between two analysis.

  • Enable cache by setting:

    sonar.cfamily.cache.enabled=true
    sonar.cfamily.cache.path=relative_or_absolute_path_to_cache_location
    

    Please note that each project should use its own path. To fully benefit of this feature you should configure your CI system to persist the cache path between runs.

  • If you prefer to not enable cache and want to turn off the console and UI warnings you should explicitly disable it by setting:

    sonar.cfamily.cache.enabled=false
    

Multithreaded Code Scan

It is possible to use all the cores available on the machine running the code scan. This can be activated by configuring the property sonar.cfamily.threads at the scanner level. Its default value is 1.

  • This feature must not be activated on a machine with only 1 core.
  • The analyzer will not guess which value is most suitable for your project. It's up to you to test and find the best value.
  • If a build machine with 2 cores is already configured to potentially run two code scans at the same time, there is no guarantee that configuring sonar.cfamily.threads=2 will bring the expected performance benefits. It can even be worse than running with the default value.
  • The multithreaded execution requires more memory than single-threaded execution.
  • A machine with 64 cores configured with sonar.cfamily.threads=64 is not certain to bring a large performance gain compared to a machine with 32 cores. The performance tradeoff will vary depending on the machine, project and setup, so some testing will be required to decide if the performance gain justifies moving to a larger machine.

Solution with a Mix of C# and C++

When you have a Solution made of C++ and C#, in order to both use the Build Wrapper and have an accurate analysis of the C# code, you must use the SonarScanner for MSBuild. The SonarScanner for MSBuild does not handle sonar-project.properties files so the Build Wrapper output directory will have to be set during the MSBuild begin step.

Note that in this scenario source code stored in shared folders, not considered as a "Project" by Visual Studio, won't be scanned.

  • Download and install both the SonarScanner for MSBuild and the Build Wrapper (see Prerequisites section).
  • Execute the SonarScanner for MSBuild begin step with the Build Wrapper output parameter /d:sonar.cfamily.build-wrapper-output=<buildwrapperoutput_directory>
  • Add execution of Build Wrapper to your normal MSBuild build command
  • Execute the SonarScanner for MSBuild end step to complete the analysis

For example:

SonarScanner.MSBuild.exe begin /k:"cs-and-cpp-project-key" /n:"My C# and C++ project" /v:"1.0" /d:sonar.cfamily.build-wrapper-output="build_wrapper_output_directory"
build-wrapper-win-x86-64.exe --out-dir build_wrapper_output_directory MSBuild.exe /t:Rebuild
SonarScanner.MSBuild.exe end

Measures for Header Files

Each time we analyze a header file as part of a compilation unit, we compute for this header the measures: statements, functions, classes, cyclomatic complexity and cognitive complexity. That means that each measure may be computed more than once for a given header. In that case, we store the largest value for each measure.

Building with Bazel

Bazel recommends that you use the --batch option when running in a Continuous Build context. When using the BuildWrapper, you are in such context. Also, you need to deactivate the "sandbox" mechanism of Bazel so that the compiled file paths could be retrieved after the compilation phase. Here is an example of the BuildWrapper command with Bazel parameters on macOS:

build-wrapper-macosx-x86 --out-dir bw bazel
  --batch
  build
  --spawn_strategy=local
  --strategy=Genrule=local
  --bazelrc=/dev/null
  //main:hello-world

Related Pages