我能期待看到这个 . .
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
为编译器算术预期的自然类型,我相信 aptrdiff_t
在这里最合适。虽然它是一个大整数。
当然这最终取决于编译器,但是很难理解为什么任何合理的编译器会在这两种情况下生成不同的代码。
我已经在 Intel 上使用 g++ 4.7.2 对此进行了测试,它们编译为相同的汇编代码。
不,选角不太可能对性能产生任何影响。这一切都在编译时解决。
我不希望,但这取决于编译器的实现。你为什么不尝试这两种方法,并计时呢?也尝试一些不同的编译器优化设置,这样您就知道在生产代码编译时它不会有所不同。
我怀疑强制转换是否会有任何汇编指令,因为(int)myEnum::A
可以在编译时评估整个表达式。
但是,如果您真的想知道,请制作一对示例程序,并通过倾倒反汇编和/或测量性能进行分析。