Support for multiple platforms and controlling C++ standard used by sonar

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);
if (something.someCondition())
// do stuff

should be:

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.

Hi @KantarBruceAdams,

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 C++17.

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.