SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
C++

C++ static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your C++ code

  • All rules 674
  • Vulnerability13
  • Bug139
  • Security Hotspot19
  • Code Smell503

  • Quick Fix 91
Filtered: 6 rules found
since-c++23
    Impact
      Clean code attribute
        1. "std::views::as_const" should be used to prevent modifying range elements

           Code Smell
        2. Escape sequences should use the delimited form (\u{}, \o{}, \x{})

           Code Smell
        3. "std::stringstream" or "std::spanstream" should be used instead of "std::strstream"

           Code Smell
        4. The underlying value of an enum should be accessed through "to_underlying"

           Code Smell
        5. "contains" should be used to test whether a substring is part of a string

           Code Smell
        6. "if consteval" should be used instead of "if (std::is_constant_evaluated())"

           Code Smell

        The underlying value of an enum should be accessed through "to_underlying"

        adaptability - focused
        maintainability
        Code Smell
        • since-c++23
        • pitfall

        C++23 introduced std::to_underlying to convert an enumeration to its underlying type.

        Why is this an issue?

        More Info

        Until C++23, in order to convert an enumerator to its underlying value, users could use static_cast:

        enum Enum: int {A, B, C};
        void foo(Enum e) {
          auto i = static_cast<int>(e); // Noncompliant: brittle
          ...
        }
        

        which is brittle because if the target type used is not the same as the underlying type of the enum, the compiler will see that an explicit cast was called and not issue a warning. That makes changing the underlying type of an existing enum dangerous as it can silently create conversion bugs.

        Or, since C++11, users could use the more robust type trait:

        enum Enum: int {A, B, C};
        void foo(Enum e) {
          auto i = static_cast<std::underlying_type_t<Enum>>(e); // Noncompliant: cumbersome
          ...
        }
        

        But this approach is cumbersome, and it can also lead to problems that the compiler will not warn about if the type of e is changed without changing the type inside the cast:

        enum Enum: int {A, B, C};
        enum AnotherEnum: int {D, E, F};
        void foo(AnotherEnum e) {
          auto i = static_cast<std::underlying_type_t<Enum>>(e); // Noncompliant: wrong type
          ...
        }
        

        Using std::to_underlying is both more robust to underlying type changes and clearer:

        enum Enum: int {A, B, C};
        void foo(Enum e) {
          auto i = std::to_underlying(e); // Compliant
          ...
        }
        

        Even when casting to another type than the underlying type, going through the underlying type first makes the purpose clear:

        enum Enum: unsigned char {A, B, C};
        void foo(Enum e) {
          auto i = static_cast<long>(e); // Noncompliant: is the target type different on purpose?
          auto j = static_cast<long>(std::to_underlying(e)); // Compliant: the type change is clearly on purpose
          ...
        }
        

        This rule raises an issue when an enum is converted to an integral value without going through a call to std::to_underlying.

        Exceptions

        The result of casting any integer type to bool does not depend on the specific integer type. For the same reason, casting an enumeration to bool does not depend on the underlying type of enumerator, so this rule does not raise.

        enum class Enum {A, B, C};
        void foo(Enum e) {
          auto i = static_cast<bool>(e); // Compliant by exception, the intent is obvious
          ...
        }
        

        Unscoped enums with no underlying type specified have an implementation-defined implicit underlying type. Calling std::to_underlying on them would not make the code more portable so this rule does not raise on them.

        enum Enum {A, B, C};
        void foo(Enum e) {
          auto i = static_cast<char>(e); // Compliant by exception, the underlying type may or may not be char
          ...
        }
        
          Available In:
        • SonarQube IdeCatch issues on the fly,
          in your IDE
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Developer Edition
          Available Since
          10.7

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use