たとえば、生成された配列が同じ長さであることを確認しやすくなるため、多くの場合、X マクロは安全性を高めると主張できます。
ただし、Misra C (2004 リファレンスから) ルールには、使用を制限する多くのプリプロセッサ ルールがあるようです。
ルール 19.1 (推奨) ファイル内の #include ステートメントの前には、他のプリプロセッサ ディレクティブまたはコメントのみを配置する必要があります。
たとえば、ソーステーブルが配列を生成するために含まれる他のファイルにある場合は面倒です。ただし、これは推奨ルールであるため、回避することができます。
規則 19.4 (必須) C マクロは、波括弧で囲まれた初期化子、定数、文字列リテラル、括弧で囲まれた式、型修飾子、ストレージ クラス指定子、または do-while-zero 構造にのみ展開されます。
ほとんどの X マクロは配列の初期化子または定数を生成するために使用されるため、問題になることはありません。
規則 19.6 (必須) #undef を使用してはならない。
一部の X マクロの使用パターンを不可能にします。残念ながら、X マクロを完全に防止するわけではありません。
ルール 19.7 (推奨) 関数は、関数のようなマクロよりも優先して使用する必要があります。
勧告ルールのみ。
ルール 19.12 (必須) # または ## プリプロセッサ演算子は、1 つのマクロ定義内で最大 1 回出現する必要があります。
ネストされたマクロを使用して回避できます。
ルール 19.13 (推奨) # および ## プリプロセッサ演算子は使用しないでください。
たとえば、列挙型を生成するときは面倒ですが、これも単なる推奨ルールです。
ルール 19.15 (必須) ヘッダー ファイルの内容が 2 回インクルードされるのを防ぐために、予防措置を講じる必要があります。
シナリオによっては面倒ですが、回避できます。
上記を見ると、気をつけていれば、Misra C コードで X-macro を使用することは可能のようです。
私の結論は正しいですか、それとも私が見逃しているルールがありますか?