これでキャスティングのパフォーマンスヒットが見られると期待できますか?。
enum class myEnum {A,B,C};
myArray[(int)myEnum::A] = 123;
これと比べて?
enum myEnum {A,B,C};
myArray[A] = 123;
私は型安全性のために新しいスタイルの列挙型クラスに傾倒していますが、パフォーマンスを犠牲にしてそれをしたくありません。
これでキャスティングのパフォーマンスヒットが見られると期待できますか?。
enum class myEnum {A,B,C};
myArray[(int)myEnum::A] = 123;
これと比べて?
enum myEnum {A,B,C};
myArray[A] = 123;
私は型安全性のために新しいスタイルの列挙型クラスに傾倒していますが、パフォーマンスを犠牲にしてそれをしたくありません。
インデックスとして使用される列挙値がコンパイル時に既知であるか、変数に渡されるかによって異なります。
つまり、ペナルティは発生しませんが、物理的な表現によってはmyArray[(int)myEnum::A]
ペナルティが発生する可能性があります(つまり、「拡張」する必要がある場合があります)。myArray[(int)e]
e
一方、単純な拡張は些細な操作であり、パフォーマンスの問題として現れる可能性はほとんどありません: 分岐予測 (条件付き) やキャッシングなどは、ほとんどのアプリケーション (低レベルの場合) ではるかに重要です。高レベルのアルゴリズムが重要です。
注: ランタイム シナリオでの拡張の問題を回避するために、 の基本型をmyEnum
、コンパイラの演算に期待される自然な型に定義することができますptrdiff_t
。ここでは a が最も適切であると思います。しかし、それは大きな整数です。
もちろん、最終的にはコンパイラ次第ですが、合理的なコンパイラがこれら 2 つのケースで異なるコードを生成する理由を理解するのは困難です。
Intel の g++ 4.7.2 でこれをテストしたところ、同じアセンブリ コードにコンパイルされました。
いいえ、キャストがパフォーマンスに影響を与える可能性は低いです。これはすべてコンパイル時に解決されます。
私はそうではないと思いますが、コンパイラの実装に依存します。両方のアプローチを試してみませんか?いくつかの異なるコンパイラー最適化設定も試してみてください。そうすれば、製品コードのコンパイルに関しては変わらないことがわかります。
(int)myEnum::A
コンパイル時に式全体を評価できるため、キャスト用のアセンブリ命令がまったく存在しないとは思えません。
しかし、本当に知りたい場合は、サンプル プログラムのペアを作成し、逆アセンブルをダンプしたり、パフォーマンスを測定したりして、両方を分析してください。