What's the plan for C++20 support?

Suggest new features New features
#1

Thanks @Alexandre_Gigleux

As C++20 is technical approved since September I want to rise the question what is SonarQube planning with this in mind. The C++ compiler support - cppreference.com are not feature complete yet but they yre on their way.

C++ analyzer helps developers to write C++17 compliant code
#2

I moved your question to the “Suggest new features” category in order to measure how popular this feature request is.

Do you have in mind some rules that would work well to get the best of C++20 standard?

#3

Some should be easy going and a start could be:

  • add reason to [[nodiscard]], i.e. prefer [[nodiscard(...)]]
  • prefer constinit if an constexpr is initialized with a const object or value
  • if comparision operators are defined, propose to define starship operator instead
  • const mismatch with defaulted copy constructor (this should already now a code smell)
  • The attribute-token s likely and unlikely shall appear at most once in each attribute-list and no attribute-argument-clause shall be present
1 Like
#4

Hello @milbrandt,

Would you mind digging a little bit deeper in some of the suggestions you made?

prefer constinit if an constexpr is initialized with a const object or value

Why would you do that? constexpr provides additional guarantees over constinit (for instance, it implies const), and I believe that in most cases, replacing constexpr by constinit would make the code less safe and less efficient. The places where constinitmake more sense I believe are exactly places where you could not before put constexpr, and had to hope the the initialization would happen at compile time.

Did I miss something?

const mismatch with defaulted copy constructor (this should already now a code smell)

I assume you are referring to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0641r2.html
I do not see what rule you expect out of this. Could you please share some example?

The attribute-token s likely and unlikely shall appear at most once in each attribute-list and no attribute-argument-clause shall be present

The standard says (9.12.6§1):

The attribute-tokens likely and unlikely shall appear at most once in each attribute-list and no attribute-argument-clause shall be present. The attribute-token likely shall not appear in an attribute-specifier-seq that contains the attribute-token unlikely.

So, what you suggests should already be enforced by the compiler. I don’t see where you think a rule would add some value here?

About your initial question

Before defining our strategy with C++20, we need to do some preliminary tests, that we currently plan to do early 2021.

On your side, can you tell us more about your needs regarding C++20? Do you use it for production code? Are you working with SonarQube :sonarqube: or SonarCloud :sonarcloud:? If you use SonarQube :sonarqube:, do you usually use the latest version, or the LTS version?

Thank you,

#5

Hello @JolyLoic,

we are using Visual Studio 2019 (16.8.x). Currently we are upgrading our projects from C++11 to C++17. Also the team had a look on C++latest (subset of C++20) and was reluctant to go the step. Code analysis availability with with SonarQube would be an argument in favour to go on this road.

At the moment we are still using Deeloper Edition 8.4.1 with Azure DevOps Server 2019. There are already some (upcoming) features I would like to get (C++17, monorepo and Azure DevOps Services integration) thus I’ll push on upgrading soon.

#6

Thank you for sharing this information with us @milbrandt!