MISRA C++:2008 Rule 9-3-3

If a member function can be made static then it shall be made static, otherwise if it can be made const then it shall be made const

説明

ルール定義

メンバー関数は static にできる場合は static にされます。また、const にできる場合は const にされます。 ¹

根拠

const メンバー関数で、クラスのデータ メンバーに変更を加えることはできません。static メンバー関数で、クラスの非静的データ メンバーに変更を加えることはできません。メンバー関数でクラスの非静的データ メンバーに変更を加える必要がない場合は、メンバー関数を const または static として宣言して、データへのアクセスを制限します。このような宣言は明確に設計の意図を表し、強制します。つまり、不注意に const メンバー関数を使用してデータ メンバーに変更を加えようとすると、コンパイラがエラーを捕捉します。const 宣言を使用しないと、このような不注意によるエラーが、検出やデバッグが難しいバグにつながる可能性があります。

Polyspace 実装

チェッカーはこれらのチェックを次の順に実行します。

1. チェッカーはまず、クラスのメンバー関数がクラスのデータ メンバーにアクセスするかどうかをチェックします。データ メンバーにアクセスしない関数は static と宣言できます。

2. チェッカーはデータ メンバーにアクセスする関数をチェックして、関数がいずれかのデータ メンバーを変更するかどうかを判断します。データ メンバーを変更しない関数は const と宣言できます。

const メンバー関数での違反は、関数がクラスのデータ メンバーにアクセスせず、static と宣言できることを意味します。

トラブルシューティング

ルール違反が想定されるものの、Polyspace^® から報告されない場合は、コーディング規約違反が想定どおりに表示されない理由の診断を参照してください。

例

データ メンバーに変更を加えないメンバー関数に対する明示的なアクセス制限

#include<cstdint>
void Connector(void);
class A
{
public:
	int16_t foo ( ) // Noncompliant 
	{
		return m_i;
	}
	int16_t foo2 ( ) // Noncompliant 
	{
		Connector();// Might have side-effect
		return m_i;
	}
	int16_t foo3 ( ) // Noncompliant
	{
		return m_s;
	}
	int16_t inc_m ( ) // Compliant 
	{
		return ++m_i;
	}
	int16_t& getref()//Noncompliant 
	{
		return m_i_ref; 
	}
private:
	int16_t m_i;
	static int16_t m_s;
	int16_t& m_i_ref;
};

この例では、Polyspace は関数 foo、foo2、foo3、および getref に、非準拠としてフラグを設定します。

• 関数 foo と foo3 は、非静的データ メンバーに変更を加えません。const として宣言されて明示的にデータ アクセスが制限されていないため、Polyspace はこれらの関数にフラグを設定します。この欠陥を修正するには、foo と foo3 を const として宣言します。

• 関数 foo2 はいずれのデータ メンバーにも明示的な変更を加えません。const として宣言されていないため、Polyspace はこの関数にフラグを設定します。foo2 はグローバル関数 Connector を呼び出すことから、副次的影響をもたらす可能性があります。foo2 を const 関数として宣言しないでください。C++11 以降では、const メンバー関数はスレッドセーフであると想定されますが、foo2 は Connector の副次的影響により、スレッドセーフにはならない可能性があります。データ レースを回避するには、foo2 を非 const 関数のままにしてください。この欠陥を正当化するには、レビュー情報またはコード コメントを使用します。

• 関数 getref はいずれのデータ メンバーにも変更を加えません。const として宣言されていないため、Polyspace はこれにフラグを設定します。getref を const として宣言するとこの欠陥は解決されますが、getref は m_i_ref の非 const 参照を返すため、その書き込みアクセスを制限するには不十分です。getref が m_i_ref に変更を加えられないようにするには、getref の戻り値の型も const でなければなりません。

チェック情報

グループ: Classes

カテゴリ: 必要

バージョン履歴

R2018a で導入

R2024b: 改善された const 修飾候補としてのクラス メンバー関数の検出

このルール チェッカーは、次のいずれかの参照を返すメンバー関数を const で修飾することを要件としなくなりました。

• 配列に含まれるデータ メンバーの要素。

• struct データ メンバーのメンバー。

たとえば、以下のコードでの MyClass クラスのメンバー関数は、このルールに準拠しています。

#include <iostream>
#include <string>

struct MyStruct {
    int id;
    std::string name;
};

class MyClass {
private:
    MyStruct myStruct;
    int myArray[10];

public:
    // Constructor to initialize struct and array
    MyClass(int id, const std::string& name, const int arr[10]) {
        myStruct.id = id;
        myStruct.name = name;
        for (int i = 0; i < 10; ++i) {
            myArray[i] = arr[i];
        }
    }

    // Function to return a reference to an element of the array
    int& getArrayElement(int index) { // Compliant
        if (index < 0 || index >= 10) {
            throw std::out_of_range("Index out of range");
        }
        return myArray[index];
    }

    // Function to return a reference to the struct's id member
    int& getStructId() { // Compliant
        return myStruct.id;
    }

    // Function to return a reference to the struct's name member
    std::string& getStructName() { // Compliant
        return myStruct.name;
    }
};

R2024a: 改善された const 修飾候補としてのクラス メンバー関数の検出

このルール チェッカーは、次のいずれかを実行するメンバー関数を const で修飾することを要件としなくなりました。

• 範囲に基づく for ループ内で、参照によってデータ メンバーを変更する。たとえば、以下に示すメンバー関数 Bar::clearFoo() は、範囲に基づく for ループを使用して配列 fooList にアクセスします。Polyspace は、このメンバー関数を const で修飾する候補と見なさなくなりました。

  #include <array>
  
  constexpr size_t MAX_FOO{ 10U };
  
  struct Foo
  {
      bool isFoo{};
  };
  
  class Bar
  {
    public:
      
      void clearFoo();
  
    private:
      std::array<Foo, MAX_FOO> fooList{};
  };
  
  
  
  void Bar::clearFoo()    // Not const - compliant
  {
      for (Foo& i : fooList) {}
  }

• データ メンバーを使用してデータ メンバーを変更する関数を呼び出す。たとえば、以下に示すメンバー関数 myFunc() は、データ メンバー myCol を使用して関数 myclass::collection::func() を呼び出します。関数 myclass::collection::func() はデータ メンバーを変更することから、Polyspace は myFunc() を const で修飾する候補と見なさなくなりました。

  class myClass
  {
  public:
  	struct collection {
  		//...
  		const char **data;
  		void func(const char **) ;
  	};
  
  	myClass::collection *getCol();
  
  	void myFunc(const char **);
  
  private:
  	collection myCol;
  };
  void myClass::collection::func(const char **foo) {
  	data = foo;
  }
  void myClass::myFunc(const char **foo)
  {
  	(&myCol)->func(foo);
  }

R2023a: 改善された const 修飾候補としてのクラス メンバー関数の検出

データ メンバーを変更する可能性があるコンストラクターにメンバー関数がデータ メンバーを渡す場合、ルール チェッカーはそのメンバー関数に対して const 修飾を要件としなくなりました。以下に例を示します。

• メンバー関数 TestClass::Test1() は、const 以外の参照を取るコンストラクターにデータ メンバー mMutex を渡します (const 参照を取るコンストラクター オーバーロードはありません)。したがって、このメンバー関数は const 修飾の候補ではありません。

• メンバー関数 TestClass::Test2() は同じデータ メンバー mMutex を、const 参照を取るコンストラクターに渡します。したがって、このメンバー関数は const 修飾の候補です。

class Item {
};

class Lock1
{
public:
    Lock1(Item& i);
};

class Lock2
{
public:
    Lock2(Item& i);
    Lock2(const Item& i);
};

class TestClass
{
public:
    void Test1() 
    {
        Lock1 lk{mMutex};
    }
    void Test2()        
    {
        Lock2 lk{mMutex};
    }
private:
    Item mMutex;
};

R2021b: 別のポインター エイリアスを使用して *this ポインターにアクセスするメンバー関数の違反は報告されない

Polyspace は、メンバー関数が別のポインター エイリアスを使用して *this ポインターにアクセスして親オブジェクトを変更する場合に、違反を報告しなくなりました。たとえば、以下のコードの関数 myRectangleClass::init はエイリアス obj を使用して *this ポインターにアクセスします。

typedef int real_T;

  class myRectangleClass {
    public:
      myRectangleClass *init(real_T a, real_T b);
      void myRectangleClass::doit(real_T a, real_T b);
      real_T Side1;
  };

  myRectangleClass *myRectangleClass::init(real_T a, real_T b)  //Compliant
  {
    myRectangleClass *obj;
    obj = this;
    obj->Side1 = a;
    return obj;
  }

Polyspace はこのような関数を const 修飾の候補と見なさなくなりました。

参考

MISRA C++:2008 をチェック (-misra-cpp)

トピック

• コーディング規約違反のチェックおよびレビュー

---

¹ All MISRA coding rules and directives are © Copyright The MISRA Consortium Limited 2021.

The MISRA coding standards referenced in the Polyspace Bug Finder™ documentation are from the following MISRA standards:

• MISRA C:2004

• MISRA C:2012

• MISRA C:2023

• MISRA C++:2008

• MISRA C++:2023

MISRA and MISRA C are registered trademarks of The MISRA Consortium Limited 2021.