为什么要使用标志+位掩码而不是布尔值序列？鉴于我有一个对象可能处于一个或多个真/假状态的情况，我总是有点模糊为什么程序员经常使用标志+位掩码而不是仅仅几个布尔值。它遍布.NET框架。不确定这是否是最佳示例，但.NET框架具有以下内容：publicenumAnchorStyles{None=0,Top=1,Bottom=2,Left=4,Right=8}因此，给定锚样式，我们A位掩码可用于确定选择哪个状态。但是，您似乎可以使用AnchorStyle类/结构完成相同的操作，其中为每个可能的值或单个枚举值的数组定义了一个bool属性。当然，我提出这个问题的主要原因是我想知道我是否应该用我自己的代码做一个类似的练习。那么，为什么要使用这种方法呢？传统上这是一种减少内存使用的方法。所以，是的，它在C#中已经很古老了:-)作为一种编程技术，它在当今的系统中可能已经过时了，您可以使用bool序列，但是...比较存储为位掩码的值很快。使用AND和OR逻辑运算符并比较生成的2个整数。它使用的内存要少得多。将所有4个示例值放在位掩码中将使用一个半字节。对于bool数组，您很可能会为数组对象使用几个字节，并为每个bool使用一个长字。如果你必须存储一百万个值，你就会明白为什么位掩码版本更优越。它更容易管理，你只需要处理一个整数值，而布尔数组将存储完全不同的东西，比如在数据库中。此外，由于内存布局，每个方面都比数组快得多。它几乎与使用单个32位整数一样快。众所周知，对于数据操作，速度最快。除此之外，向位域添加新的位含义比向类添加新的布尔值更容易。将位域从一个实例复制到另一个实例比将一系列布尔值复制更容易。它还使方法更加清晰。想象一种方法，其中将10个布尔值与1个位掩码进行比较。实际上，它可以有更好的性能，主要是因为你的枚举来自一个字节。在这种极端情况下，每个枚举值将由一个字节表示，包含所有组合，最多256个。拥有这么多可能的接线组合将产生256个字节。但是，即使那样，我也不认为这是真正的原因。我更喜欢这些的原因是C#让我处理这些枚举的强大功能。我可以用一个表达式添加多个值。我也可以删除它们。我什至可以使用枚举来一次比较几个值。对于布尔值，代码会变得更加冗长。RaymondChen有一篇关于此主题的博文。当然，位域保存数据内存，但您必须在代码大小、可调试性和降低多线程成本之间取得平衡。正如其他人所说，它的时间基本上结束了。这样做仍然很容易，因为摆弄一点很有趣也很酷，但它不再更有效率，它在维护方面有严重的缺点，它不能很好地与数据库配合使用，除非你是嵌入一??个世界，你有足够的内存。我建议永远不要使用枚举标志，除非你正在处理一些非常严重的内存限制（不太可能）。您应该始终编写针对维护进行优化的代码。拥有多个布尔属性可以更轻松地阅读和理解代码、更改值和提供智能感知注释，更不用说出现错误的可能性更小了。如有必要，您始终可以在内部使用枚举标志字段，只需确保使用布尔属性公开值的设置/获取。从领域模型的角度来看，它只是在某些情况下更好地模拟现实。如果您有三个布尔值，如AccountIsInDefault和IsPreferredCustomer以及RequiresSalesTaxState，将它们添加到单个Flags装饰枚举是没有意义的，因为它们不是同一域模型元素的三个不同值。但是，如果您有一组这样的布尔值：[Flags]enumAccountStatus{AccountIsInDefault=1,AccountOverdue=2andAccountFrozen=4}或[Flags]enumCargoState{ExceedsWeightLimit=1,ContainsDangerousCargo=2,IsFlammableCargo=4,ContainsRadioactive=8}然后，能够将帐户（或商品）的总状态存储在一个变量中会很有用……表示一个域元素，其值可以表示任何可能的状态组合。节省空间-1位节省时间-位由硬件快速处理。语言独立性——数据可能由许多不同的程序处理，您不必担心跨不同语言/平台强制执行布尔值。大多数时候，这些不值得维护权衡。但是，有时它很有用：网络协议-减小消息大小会节省很多遗留软件-一旦我不得不添加一些信息来追踪一些遗留软件。修改标题的成本：数百万美元和多年的努力。将信息塞入标头中未使用的2个字节的成本：0。当然，访问和操作此信息的代码会产生额外成本，但这都是由函数完成的，因此一旦定义了访问器，它就不像使用布尔值。这是为了速度和效率。基本上你使用的只是一个int。以上就是C#学习教程：为什么要用flags+bitmasks而不是一系列的布尔值？如果分享的内容对你有用，需要进一步了解C#学习教程，希望你多多关注——if((flags&AnchorStyles.Top)==AnchorStyles.Top){//Dostuff}这个文章来自网络收藏，不代表立场，如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
