いくつかの理由:
理由 1: 柔軟性:
enum lickahoctor { yes = 0, no = 1, maybe = 2 };
列挙を宣言します。値 と を任意のyes
場所no
でmaybe
使用して、任意の整数型に割り当てることができます。これを型として使用することもできます。
enum lickahoctor myVar = yes;
関数が enum lickahoctor 型のパラメーターを受け取る場合yes
、no
またはmaybe
を割り当てることができることがわかるため、これは便利です。また、デバッガーはそれを認識するため、数値の代わりに記号名を表示します。enum lickahoctor
問題は、コンパイラが に定義した値しか代入できないことですmyVar
。たとえば、基本クラスでいくつかのフラグを定義し、サブクラスでさらにいくつかのフラグを追加する場合、この方法では実行できません。
代わりに int を使用すると、その問題は発生しません。したがって、ある種の int を使用したいので、任意の定数を割り当てることができます。
理由 2: バイナリ互換性:
コンパイラは、列挙型で定義したすべての定数に適合する適切なサイズを選択します。何が得られる保証はありません。そのため、そのような変数を含む構造体をファイルに直接書き込んだ場合、アプリの次のバージョンで再度読み込んだときに同じサイズであるという保証はありません (少なくとも C 標準によれば、 -実際にはそれほど暗くはありません)。
代わりにある種の int を使用すると、プラットフォームは通常、その数値に対して特定のサイズを保証します。特に、int32_t
/のように、特定のサイズであることが保証されているタイプのいずれかを使用する場合uint32_t
。
理由 3: 読みやすさと自己文書化
上で myVar を宣言すると、どのような値を入れることができるかがすぐにわかります。int または のみを使用する場合はuint32_t
、そうではありません。だからあなたがすることはあなたが使うことです
enum { yes, no, maybe };
typedef uint32_t lickahoctor;
このタイプの変数がこの値を保持できることを人々に思い出させるために、定数の近くのどこかに整数の素敵な名前を定義します。ただし、予測可能な固定サイズと、必要に応じてサブクラスで追加の値を定義する機能の利点は引き続き得られます。
理由 4: ビットフィールドのサポート
列挙型の変数は、オプションから正確に 1 つの値の割り当てのみをサポートします。したがって、ビット フィールドを実装しようとしている場合、それをビットフィールドとして入力することはできません。さらに、符号拡張があなたを台無しにするのを避けるために、符号なし変数を使用する必要があります。