在声明枚举时,是否应该将类型强制为256个实体以下的字节？

Question

如果你的应用程序中有一个枚举而你只有几个项目,那么你应该强制基础类型是最小的类型吗？

    enum smaller : byte
    {
        one,
        two,
        three
    };

Answer 1

不.不要过早地优化,除非你用剖析器证明它实际上是一个问题.

你如何用剖析器证明byte或int是否更有效？ (3认同)
我从不同的角度来看这个.我写了很多网络和串行协议,其中包含正确类型的变量很重要.为了方便和防止错误,我使用UInt32 UInt16等代替uint,ushort等.在我的情况下,我通常强制枚举类型匹配协议定义,以便我可以直接序列化它. (3认同)
要明确的是,我讨论的是最佳实践而不是优化,尽管这个问题是一个优化问题.我的观点真的是因为你可以指定它,你应该"总是"指定或者你应该让编译器决定吗？我想离开是为两者都有效. (2认同)

Answer 2

与最佳做法有关:

如果没有特殊原因使枚举成为类型字节,则应将其保留为默认值.

无论何时在switch语句中使用枚举,都应该为无效的枚举值设置"default"子句.因此,如果要检查256-NumRealEnumValues或2 ^ 32-NumRealEnumValues,则无关紧要.两者都有一个处理所有无效情况的默认子句.

显式设置枚举类型的一个原因是,如果您希望枚举与程序中的其他类型相对应,则需要在它们之间显式转换.

将类型更改为最小拟合也无助于解决版本问题.除非您确实填写了枚举的最大大小.通过版本化问题我的意思是当你使用枚举编译dll时,然后你添加一个新的枚举值,一些代码可能会执行,而不是在switch语句的"default"子句中.

与效率有关:

在效率方面没有任何好处使它成为一个字节.

int的使用效率更高,因为x86上的cpu具有32位寄存器.复制到寄存器一次是32位.

当您使用较小的类型时,必须将寄存器的一部分归零并复制到寄存器的低阶位的其余部分.

您只考虑CPU性能.虽然将所需寄存器位清零的成本几乎可以忽略不计,但内存使用效率的提高可能会很大. (4认同)
“可以是实质性的”在技术上是正确的，但我怀疑它是否会经常被证明是实质性的。根据我的经验，单个字节（不在数组中）通常会填充到字边界，因此许多字节占用的内存与 int 一样多。 (2认同)
当我在结构中使用枚举时怎么样？我是否需要将它们缩小为字节以使整个结构更小？ (2认同)
绝对需要是一个字节，例如，如果它是一个实体框架实体属性，您希望它是一个字节，并且如果它是集群键的一部分，那么保持它很小就特别重要。 (2认同)

Answer 3

执行此操作的唯一原因是,如果您使用定义的协议存储或传输此值,该协议要求字段具有该大小.

我不会说这是唯一的原因.我经常这样做是因为我需要在内存中保留一亿或更多的项目,每个记录节省的三个字节非常重要. (4认同)
@Juliano我不认为这表明其他地方有问题.在实时算法交易的世界中,您通常需要一次在内存中保留数百万个数据项(例如,交易,订单簿更新).每个数据项削减3个字节会产生显着的好处. (4认同)