枚举是否限制了C＃中的成员？

Question

我想知道枚举结构类型是否对其成员有限制。我有一个非常大的“变量”列表，我需要存储在枚举中或作为类中的常量但我最终决定将它们存储在类中，但是，我对成员的限制有点好奇一个枚举（如果有的话）。

那么，枚举对.Net有限制吗？

Answer 1

是。具有不同值的成员的数量受基础类型enum的限制 - 默认情况下为Int32，因此您可以获得许多不同的成员（2 ^ 32 - 我发现你很难达到这个限制），但是你可以明确地指定基础类型：

enum Foo : byte { /* can have at most 256 members with distinct values */ }

当然，如果它们都具有相同的值，您可以拥有任意数量的成员：

enum { A, B = A, C = A, ... }

在任何一种情况下，C＃编译器中都可能有一些实现定义的限制，但我希望它是MIN（Int32范围，可用内存），而不是硬限制。

Answer 2

由于PE文件格式的限制，您可能不会超过约100,000,000个值。也许更多，也许更少，但绝对不是问题。

Answer 3

来自C# Language Specification 3.0，1.10：

  

枚举类型的存储格式和   可能值的范围是   由其基本类型决定。

虽然我不是100％肯定我会期望Microsoft C＃编译器只允许非负的枚举值，所以如果底层类型是Int32（默认情况下是这样）那么我预计会有大约2 ^ 31个可能的值，但这是一个实现细节，因为它没有指定。如果你需要更多，你可能做错了。

Answer 4

理论上你可以在枚举中使用int64作为基类型，并获得2 ^ 63个可能的条目。其他人已就此给出了很好的答案。

我认为，对于包含大量项目的内容，如果你使用枚举，还有第二个隐含的问题。这实际上直接适用于您的项目。

最重要的考虑因素之一是长期可维护性。您认为公司是否会更改您正在使用的值列表？如果是这样，是否需要向后兼容以前的列表？问题有多重要？通常，枚举中成员的数量越大，则在将来某个日期需要修改列表的概率越高。

Enums很适合很多事情。它们干净，快速且易于实施。它们与IntelliSense配合使用，使下一个程序员的工作变得更加容易，特别是如果名称清晰，简洁，并且需要，并且有详细记录。

问题是枚举也有缺点。如果需要更改它们，它们可能会有问题，特别是如果使用它们的类被持久存储。

在大多数情况下，枚举会持久存储作为其基础值，而不是其友好名称。

enum InsuranceClass
  {
   Home,     //value = 0 (int32)
   Vehicle,  //value = 1 (int32)
   Life,     //value = 2 (int32)
   Health    //value = 3 (int32)
  }

在此示例中，值InsuranceClass.Life将保持为数字2。

如果另一个程序员对系统进行了一些小改动，并将Pet添加到这样的枚举中;

enum InsuranceClass
  {
   Home,     //value = 0 (int32)
   Vehicle,  //value = 1 (int32)
   Pet,      //value = 2 (int32)
   Life,     //value = 3 (int32)
   Health    //value = 4 (int32)
  }

现在，存储中的所有数据都会将生活政策显示为宠物政策。这是一个非常容易犯的错误，可能会引入难以追踪的错误。

枚举的第二个主要问题是，每次更改数据都需要您重建和重新部署程序。这可能导致不同程度的疼痛。在可能不是大问题的Web服务器上，但如果这是在5000台桌面系统上使用的应用程序，则重新部署次要列表更改的成本完全不同。

如果您的列表可能会定期更改，您应该考虑一个以其他形式存储该列表的系统，很可能在您的代码之外。数据库是专门为这种情况设计的，甚至可以使用简单的配置文件（不是优先解决方案）。智能的变更计划可以减少或避免与重建和重新部署软件相关的问题。

这并不是建议过早地优化系统的变更可能性，而是建议构建代码，以便将来可能发生的变化不会产生重大问题。不同的情况需要做出不同的决定。

以下是我使用枚举的粗略经验法则;

1. 使用它们来分类和定义其他数据，但不能作为数据 他们自己。为了更清楚，我会使用InsuranceClass.Life来 确定如何使用类中的其他数据，但我会 不要使{pseudocode} InsuranceClass.Life = $653.00和{{1}}的潜在价值 在计算中使用值本身。枚举不是常量。干 这造成了混乱。
2. 枚举列表不太可能更改时使用枚举。枚举很棒 对于基本概念，但对于不断变化的想法很差。 创建枚举时，这是与未来的契约 你想避免破坏的程序员。
3. 如果您必须更改枚举，那么请遵循规则 你添加到最后，而不是中间。替代方案是你 为每个枚举定义特定值，永远不会更改它们。该 重点是你不太可能知道其他人如何使用你的 枚举基础值并改变它们可能会给任何人带来痛苦 否则使用你的代码。这是一个更重要的数量级 对于任何持久保存数据的系统。
4. ＃2和＃3的必然结果是永远不要删除枚举的成员。 对于在其他人使用的代码库中执行此操作的程序员来说，有一些特定的地狱圈。

希望以有用的方式扩展答案。