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: 62 rules found
since-c++11
    Impact
      Clean code attribute
        1. A single L in a literal suffix should only be used for long values

           Code Smell
        2. "static_assert" should be preferred to assert when the argument is a compile-time constant

           Code Smell
        3. Perfect forwarding constructors should be constrained

           Bug
        4. rvalue reference members should not be copied accidentally

           Code Smell
        5. "auto" should be used to store a result of functions that conventionally return an iterator or a range

           Code Smell
        6. "emplace" should be prefered over "insert" with "std::set" and "std::unordered_set"

           Code Smell
        7. Unnecessary expensive copy should be avoided when using auto as a placeholder type

           Code Smell
        8. The right template argument should be specified for std::forward

           Code Smell
        9. Exception specifications should be treated as part of the type

           Code Smell
        10. Free functions should be preferred to member functions when accessing a container in a generic context

           Code Smell
        11. Objects should not be created solely to be passed as arguments to functions that perform delegated object creation

           Code Smell
        12. Emplacement should be preferred when insertion creates a temporary with sequence containers

           Code Smell
        13. "bind" should not be used

           Code Smell
        14. "std::initializer_list" constructor should not overlap with other constructors

           Code Smell
        15. Threads should not be detached

           Code Smell
        16. "shared_ptr" should not be taken by rvalue reference

           Code Smell
        17. Inheriting constructors should be used

           Code Smell
        18. "make_unique" and "make_shared" should be used to construct "unique_ptr" and "shared_ptr"

           Code Smell
        19. "auto" should be used to avoid repetition of types

           Code Smell
        20. Multiple mutexes should not be acquired with individual locks

           Code Smell
        21. Pointers or references obtained from aliased smart pointers should not be used as function parameters

           Code Smell
        22. "try_lock", "lock" and "unlock" should not be directly used for mutexes

           Code Smell
        23. Function parameters that are rvalue references should be moved

           Code Smell
        24. Capture by reference in lambdas used locally

           Code Smell
        25. "Forwarding references" parameters should be used only to forward parameters

           Code Smell
        26. "std::move" and "std::forward" should not be confused

           Bug
        27. "using" should be preferred for type aliasing

           Code Smell
        28. "std::move" should only be used where moving can happen

           Code Smell
        29. Functions that throw exceptions should not be used as hash functions

           Code Smell
        30. "constexpr" functions should not be declared "inline"

           Code Smell
        31. A call to "wait()" on a "std::condition_variable" should have a condition

           Bug
        32. "std::move" should not inhibit optimizations

           Code Smell
        33. Moved-from objects should not be relied upon

           Code Smell
        34. Functions which do not return should be declared as "noreturn"

           Code Smell
        35. Memory should not be managed manually

           Code Smell
        36. Facilities in <random> should be used instead of "srand", "rand" and "random_shuffle"

           Code Smell
        37. Lambdas that capture "this" should capture everything explicitly

           Code Smell
        38. Move and swap operations should be "noexcept"

           Code Smell
        39. Function parameters should not be of type "std::unique_ptr<T> const &"

           Code Smell
        40. "std::auto_ptr" should not be used

           Bug
        41. "nullptr" should be used to denote the null pointer

           Code Smell
        42. "auto" should not be used to deduce raw pointers

           Code Smell
        43. Local variables and member data should not be volatile

           Code Smell
        44. Destructors should be "noexcept"

           Bug
        45. Scoped enumerations should be used

           Code Smell
        46. "const" and "volatile" should not be used in "enum" declarations

           Code Smell
        47. Raw string literals should be used

           Code Smell
        48. "static" should not be used in unnamed namespaces

           Code Smell
        49. Default capture should not be used

           Code Smell
        50. "final" classes should not have "virtual" functions

           Code Smell
        51. Redundant lambda return types should be omitted

           Code Smell
        52. Special member function should not be defined unless a non standard behavior is required

           Code Smell
        53. "override" or "final" should be used instead of "virtual"

           Code Smell
        54. "final" classes should not have "protected" members

           Code Smell
        55. "final" should not be used redundantly

           Code Smell
        56. Lambdas should not be used

           Code Smell
        57. Lambdas should not have too many lines

           Code Smell
        58. A non-"transient lambda" shall not implicitly capture "this"

           Code Smell
        59. "Unscoped enumerations" should not be declared

           Code Smell
        60. "Forwarding references" and "std::forward" shall be used together

           Code Smell
        61. Variables should be captured explicitly in a non-"transient lambda"

           Code Smell
        62. "nullptr" shall be the only form of the "null-pointer-constant"

           Code Smell

        Moved-from objects should not be relied upon

        intentionality - logical
        maintainability
        Code Smell
        • symbolic-execution
        • cert
        • since-c++11

        Relying on an object that has been moved-from leads to undefined behavior in most cases.

        Why is this an issue?

        How can I fix it?

        More Info

        After a move took place, the object that has been moved-from is left in a valid but unspecified state. Even if in a valid state, the fact of an object being in an unspecified state may lead to undefined behavior.

        Move construction and its respective move semantics has been introduced in C++11. Moving objects becomes interesting if one wishes to get an object into a different scope, while no longer requiring the original object. While one would previously need to make a potentially expensive copy to get an object into another scope and then destroy the original, move constructors allow one to move objects without performing a copy. Move constructors are typically implemented by "stealing" the resources held by another object specified as the move constructor’s parameter, rather than making a copy. "Stealing" resources (e.g. memory) from another object is oftentimes much more efficient than making a copy and destroying the original, and can frequently be implemented by reassigning a few pointer variables.

        Move-assignment operators behave analogously, except that they are used once the object that is moved-to has already been constructed. In contrast to copy-assignment operators, a move-assignment operator too "steals" the moved-from object’s resources without the need for making a potentially expensive copy.

        What is the potential impact?

        Using an object after it has been moved-from typically leads to undefined behavior.

        For programs that exercise undefined behavior, the compiler is no longer bound by the language specification. The application may crash or, even worse, the application may appear to execute correctly while losing data or producing incorrect results.

        Trying to access an object that has been moved-from frequently ends up in a null-pointer dereference, since any pointers to the resources that have been "stolen" are set to nullptr as part of the move construction or move assignment.

        Exceptions

        There are some C++ standard template library types, such as std::unique_ptr, for which the moved-from state is fully specified.

        Exemplary type with move operations

        The DynamicIntArray type defined in the following manages memory (i.e., a resource), and shall serve as an example that showcases how move operations "steal" another object’s resources and how they differ from making copies.

        While the copy constructor does make a full copy by allocating memory and then copying the other object’s array values into the freshly allocated memory, the move constructor only assigns the pointer to point to other's dynamically allocated memory. It then sets the pointer of the other object to nullptr to allow its correct cleanup by the destructor of the DynamicIntArray type.

        The implementations for the copy- and move-assignment operators are similar with the main difference being that the objects have already been constructed.

        #include <algorithm> // std::copy, std::fill
        #include <memory>    // std::move
        
        class DynamicIntArray {
          size_t size;
          int *data;
        
        public:
          explicit DynamicIntArray(size_t size, int initial_value)
              : size(size), data(new int[size]) {
            std::fill(data, &data[size], initial_value);
          }
          ~DynamicIntArray() {
            delete[] data;
            size = 0;
          }
          // Copy constructor (copies object)
          DynamicIntArray(DynamicIntArray const &other)
              : size(other.size), data(new int[other.size]) {
            std::copy(other.data, &other.data[size], data);
          }
          // Move constructor ("steals" data, no allocation or copy necessary)
          DynamicIntArray(DynamicIntArray &&other) noexcept
              : size(other.size), data(other.data) {
            // Ensure that the moved-from object `other` can be safely destroyed (using
            // the destructor that calls to delete[]).
            other.data = nullptr;
            other.size = 0;
          }
          //
          // Copy- and move-assignment operators are invoked, if _this_ object has
          // already been constructed.
          //
          // Copy-assignment operator (copies object)
          DynamicIntArray &operator=(DynamicIntArray const &other) {
            // If the number of elements are equal, we can re-use the existing memory.
            if (size == other.size) {
              std::copy(other.data, &other.data[other.size], data);
              return *this;
            }
            // Otherwise, we need to clean-up and re-allocate the required amount of
            // memory.
            delete[] data;
            data = new int[other.size];
            size = other.size;
            std::copy(other.data, &other.data[size], data);
            return *this;
          }
          // Move-assignment operator ("steals" data, no allocation or copy necessary)
          DynamicIntArray &operator=(DynamicIntArray &&other) noexcept {
            delete[] data; // Clean-up our own data before we "steal" from `other`.
            data = other.data;
            size = other.size;
            // Ensure that the moved-from object `other` can be safely destroyed (using
            // the destructor that calls to delete[]).
            other.data = nullptr;
            other.size = 0;
            return *this;
          }
        
          int &getValueAt(size_t idx) { return data[idx]; }
        };
        
        int main() {
          DynamicIntArray a{/*size=*/128, /*initial_value=*/42};
          DynamicIntArray b = a;            // Copy constructor.
          DynamicIntArray c = std::move(b); // Move constructor.
          // Construct two more objects.
          DynamicIntArray d{/*size=*/4, /*initial_value=*/0};
          DynamicIntArray e{/*size=*/8, /*initial_value=*/9001};
          // Use the assignment operators.
          a = d;            // Copy-assignment operator.
          c = std::move(e); // Move-assignment operator.
          int i = b.getValueAt(0); // Noncompliant: `b` has been moved-from during construction of `c`.
          int j = e.getValueAt(0); // Noncompliant: `e` has been moved-from during move-assignment to `c`.
          return i + j;
        }
        
          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
          9.1

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use