I have a project which is build for multiple platforms. For each platform the C++ standard is set to the maximum possible - so that we can work towards compliance with the latest standard.
The code itself, however, has to conformed to the lowest common standard with whatever ‘polyfills’ we have added to replicate newer behaviours on old versions of the standard.
The problem is the build wrapper detects C++17 and identifies smells such as:
const auto something(param1);
// do stuff
if ( const auto something(param1); something.someCondition())
// do stuff
Which is not legal before C++17.
For this project the sonar analysis is run for the build on the platform which a compiler that supports C++17 not the earlier compiler.
Can we set the sonar standard to an earlier standard and override the standard identified by the build wrapper?
I would rather not disable individual rules so that we can upgrade to a later standard in one go when possible.
Note also that the build wrapper is capturing “-std=gnu++1y”
but I expect sonar knows enough about gcc to know which subsets of C++17 this includes.
As a workaround I could alter the build script to replace this line in the build-wrapper-dump.json but I would rather treat this file as opaque and not depend on how sonar happens to be implemented.
This is similar to this issue C++: Set C++ version (14, 17, ...) to execute checks for.
However for that case he was using an old version of the scanner which did not automatically select rules based on the C++ standard identified by the build wrapper.
We don’t have this granularity. Compilers change fast. Keeping track of what feature is supported by transitional flags like
-std=gnu++1y isn’t maintainable.
-std=gnu++1y depends on GCC version and the same for other compilers.
We identify each project as one of C++ 98/11/13/17/20 standards.
We automatically disable/enable some rules based on the standard in the build wrapper and the following tags:
Also, we adjust the suggested fix based on the detected standard.
Is selecting all the issues with
since-c++17 and bulk marking them as
won't fix solve your problem? later you can reopen them when you can use
Or do you prefer not to see
C++17 issues at all?
And just to be clear, we have an internal option to set the reporting standards explicitly, I’m just trying to understand your exact need to suggest the best solution.
We added the following option, that you can use (It should show up in the documentation once a bug is fixed)
Targeted C++ standard
The analyzer targets a specific version of the C++ language to tune the rules in the activated quality profile. This reporting standard is used to:
- Suppress rules that cannot be applied. For example, rules that suggest using
c++20 features while the code is compiled with
- Adjust rules’ messages to suggest the proper fix according to the used standard. For example, a rule that suggest using
c++20 will be tuned to suggest using
std::any_of with older standard.
By default, the reporting standard version is the version that is used to compile the code. This is ideal for most projects. However, there are some edge cases where there is a need to use a reporting standard that is different from the compilation standard. For this reason, we provide the following scanner property to adjust the reporting standard:
This property is only recommended to be used in the case where a project has to comply with a standard older than the one it is compiled with. This can happen if:
- The compiler doesn’t allow to set a specific standard. For example, MSVC doesn’t allow specifying a standard older than
- The project wants to be compiled with the latest standard while still being compliant with an older standard.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.