使用-1将所有位设置为true是否安全？

我已经看到这种模式在C＆C ++中使用了很多。

unsigned int flags = -1;  // all bits are true

这是完成此任务的一种好方法吗？还是使用0xffffffff或~0更佳？

我建议您严格按照显示的方法进行操作，因为这是最直接的方法。初始化-1将始终起作用，而与实际的符号表示无关，而~有时会出现令人惊讶的行为，因为您必须具有正确的操作数类型。只有这样，您才能获得unsigned类型的最高价值。

有关一个可能令人惊讶的示例，请考虑以下示例：

unsigned long a = ~0u;

它不一定会存储所有位为1的模式a。但是它将首先使用中的所有位1创建一个模式unsigned int，然后将其分配给a。当unsigned long具有更多位时发生的事情是并非所有这些都为1。

并考虑这一点，它将因非二进制补码表示而失败：

unsigned int a = ~0; // Should have done ~0u !

这样做的原因是~0必须将所有位取反。反转，将产生-1一个补台机器上（这是我们所需要的值！），但将不会产生-1对另一种表示。在一个补码机上，它的值为零。因此，在一个人的补码机器上，以上将初始化a为零。

您应该了解的是，这全都与值有关，而不是位。变量使用值初始化。如果在初始化器中修改了用于初始化的变量的位，则将根据这些位生成值。要初始化a为可能的最大值，您需要的值为-1或UINT_MAX。第二个将取决于类型a-你将需要使用ULONG_MAX一个unsigned long。但是，第一个将不取决于其类型，这是获得最高价值的一种好方法。

我们不是在讨论是否-1所有位都为1（并非总是都有）。而且，我们并不是在说~0所有位是否都为1（当然，它是否全部为1）。

但是，我们所说的是初始化flags变量的结果是什么。因此，仅-1适用于每种类型和机器。

• unsigned int flags = -1; 是便携式的。
• unsigned int flags = ~0; 不可移植，因为它依赖于二进制补码表示。
• unsigned int flags = 0xffffffff; 不可移植，因为它采用32位整数。

如果要以C标准保证的方式设置所有位，请使用第一个。

坦白地说，我认为所有fff都更具可读性。关于它是反模式的评论，如果您真的在乎所有位都已设置/清除，那么我会认为您可能处于无论如何都在乎变量大小的情况下，这需要使用boost等方法。 :: uint16_t等

避免出现上述问题的方法是简单地执行以下操作：

unsigned int flags = 0;
flags = ~flags;

轻便且指向重点。

我不确定使用无符号int作为标记在C ++中是不是一个好主意。比特集之类的呢？

std::numeric_limit<unsigned int>::max()更好，因为0xffffffff假定unsigned int是一个32位整数。

unsigned int flags = -1;  // all bits are true

“这是实现此目的的一种好方法吗？”

随身携带？ 是的。

好？ 值得商bat的，此线程上显示的所有混乱证明了这一点。足够清晰，以使您的同行程序员可以理解代码而不会引起混淆，这应该是我们衡量良好代码的维度之一。

另外，此方法容易产生编译器警告。要消除警告而不损害编译器，您需要显式强制转换。例如，

unsigned int flags = static_cast<unsigned int>(-1);

显式强制转换要求您注意目标类型。如果您关注目标类型，那么您自然会避免其他方法的陷阱。

我的建议是要注意目标类型，并确保没有隐式转换。例如：

unsigned int flags1 = UINT_MAX;
unsigned int flags2 = ~static_cast<unsigned int>(0);
unsigned long flags3 = ULONG_MAX;
unsigned long flags4 = ~static_cast<unsigned long>(0);

所有这些对您的程序员都是正确的，并且更加显而易见。

并且使用C ++ 11：我们可以auto使这些更简单：

auto flags1 = UINT_MAX;
auto flags2 = ~static_cast<unsigned int>(0);
auto flags3 = ULONG_MAX;
auto flags4 = ~static_cast<unsigned long>(0);

我认为正确和明显比单纯正确更好。

标准保证将-1转换为任何无符号类型会导致全为1。~0U通常使用不好，因为0具有类型，unsigned int并且不会填充较大的无符号类型的所有位，除非您明确编写类似的内容~0ULL。在理智的系统上，~0应与相同-1，但由于该标准允许以1补码和符号/幅度表示，因此严格来说，它不是可移植的。

当然，0xffffffff如果您知道确实需要32位，也可以写出来，但是-1的优点是，即使您不知道类型的大小，它也可以在任何上下文中运行，例如可以在多种类型上使用的宏，或者类型的大小因实现而异。如果你知道的类型，另一种安全的方式来获得所有的人已是极限宏UINT_MAX，ULONG_MAX，ULLONG_MAX，等。

我个人总是使用-1。它始终有效，您不必考虑它。

只要您有#include <limits.h>一个包含项，就应该使用

unsigned int flags = UINT_MAX;

如果您想买多头钱，可以使用

unsigned long flags = ULONG_MAX;

无论如何实现带符号整数，这些值都保证将结果的所有值位都设置为1。

是。如其他答案所述，-1它是最可移植的；但是，它不是很语义，会触发编译器警告。

要解决这些问题，请尝试使用以下简单的帮助器：

static const struct All1s
{
    template<typename UnsignedType>
    inline operator UnsignedType(void) const
    {
        static_assert(std::is_unsigned<UnsignedType>::value, "This is designed only for unsigned types");
        return static_cast<UnsignedType>(-1);
    }
} ALL_BITS_TRUE;

用法：

unsigned a = ALL_BITS_TRUE;
uint8_t  b = ALL_BITS_TRUE;
uint16_t c = ALL_BITS_TRUE;
uint32_t d = ALL_BITS_TRUE;
uint64_t e = ALL_BITS_TRUE;

我不会做-1的事情。这是相当不直观的（至少对我而言）。将有符号数据分配给无符号变量似乎违反了事物的自然顺序。

在您的情况下，我始终使用0xFFFF。（当然，对于可变大小，请使用正确数量的Fs。）

[顺便说一句，我很少看到在实际代码中完成-1技巧。

此外，如果你真的关心在vairable的各个位，这将是不错的主意，开始使用固定宽度uint8_t，uint16_t，uint32_t类型。

在Intel的IA-32处理器上，可以将0xFFFFFFFF写入64位寄存器并获得预期的结果。这是因为IA32e（IA32的64位扩展名）仅支持32位立即数。在64位指令中，对32位立即数进行符号扩展为64位。

以下是非法的：

mov rax, 0ffffffffffffffffh

以下代码在RAX中放入64个1：

mov rax, 0ffffffffh

为了完整起见，以下将32 1放在RAX（又名EAX）的下部：

mov eax, 0ffffffffh

实际上，当我想将0xffffffff写入64位变量时却遇到了程序失败，而我却得到了0xffffffffffffffffff。在C中，它将是：

uint64_t x;
x = UINT64_C(0xffffffff)
printf("x is %"PRIx64"\n", x);

结果是：

x is 0xffffffffffffffff

我想将其发布为所有回答的注释，这些回答说0xFFFFFFFF假定为32位，但是很多人回答了它，所以我认为我会将其添加为单独的答案。

有关问题的非常清晰的说明，请参见litb的答案。

我的不同意是，严格来说，这两种情况都不能保证。我不知道有没有一种架构能代表所有位都设置成无符号值“位数小于2的幂”，但这就是标准的实际含义（3.9.1 / 7加注释44）：

整数类型的表示应使用纯二进制计算系统定义值。[注44：]使用二进制数字0和1的整数的位置表示，其中连续位表示的值是加法的，从1开始，然后乘以连续的2的整数幂，除了可能的位是最高的位置。

这就使这些位之一完全可能成为任何东西的可能性。

尽管0xFFFF（或0xFFFFFFFF等）可能更易于阅读，但它可能破坏代码的可移植性，否则这些代码将是可移植的。例如，考虑一个库例程，该例程计算一个数据结构中有多少项已设置了某些位（确切的位由调用者指定）。该例程对于位表示什么可能是完全不可知的，但是仍然需要具有“所有位设置”常量。在这种情况下，-1将比十六进制常数好得多，因为它可以在任何位大小下工作。

如果将typedef值用于位掩码，则另一种可能性是使用〜（bitMaskType）0; 如果位掩码恰好是16位类型，则该表达式将只设置16位（即使'int'否则为32位），但由于只需要16位，因此只要一个实际上在类型转换中使用适当的类型。

顺便说一句，longvar &= ~[hex_constant]如果十六进制常数太大而不能放入，则该形式的表达式会令人讨厌int，但是会适合unsigned int。如果an int为16位，则为longvar &= ~0x4000;或longvar &= ~0x10000；会清除的一位longvar，但longvar &= ~0x8000;会清除第15位及以上的所有位。合适的值int将对类型应用补数运算符int，但结果将符号扩展为long，从而设置高位。太大的值unsigned int将把补数运算符应用于type long。但是，介于这些大小之间的值会将补数运算符应用于type unsigned int，然后将其转换为long没有符号扩展名的type 。

实际上：是的

理论上：不。

-1 = 0xFFFFFFFF（或平台上int的任何大小）仅适用于二进制补码算法。实际上，它可以工作，但是那里有旧式机器（IBM大型机等），在该机器中您具有实际的符号位，而不是二进制补码。您建议的〜0解决方案应该可以在任何地方使用。

正如其他人提到的，-1是创建整数的正确方法，该整数将转换为所有位都设置为1的无符号类型。但是，C ++中最重要的事情是使用正确的类型。因此，对您的问题的正确答案（包括对您所提出问题的答案）是：

std::bitset<32> const flags(-1);

这将始终包含所需的确切位数。std::bitset出于其他答案中提到的相同原因，它构造一个所有位都设置为1的a 。

这肯定是安全的，因为-1将始终设置所有可用位，但是我更喜欢〜0。-1只是没有太大的意义unsigned int。0xFF...不好，因为它取决于类型的宽度。

我说：

int x;
memset(&x, 0xFF, sizeof(int));

这将始终为您提供所需的结果。

利用为无符号类型将所有位分配给一个位的事实等同于为给定类型采用最大可能值，
并将问题的范围扩展到所有无符号整数类型：

为C和C ++的任何无符号整数类型（无符号int，uint8_t，uint16_t等）分配-1均有效。

或者，对于C ++，您可以：

1. 包含<limits>和使用std::numeric_limits< your_type >::max()
2. 编写自定义模板函数（这还将允许进行完整性检查，即，如果目标类型确实是未签名的类型）

目的可以更加清晰，因为分配-1总是需要一些解释性的意见。

一种使含义更明显但又避免重复该类型的方法：

const auto flags = static_cast<unsigned int>(-1);

是的，显示的表示形式非常正确，就像我们以另一种方式进行处理时，您将需要运算符反转所有位，但是在这种情况下，如果我们考虑机器中整数的大小，逻辑将非常简单

例如在大多数机器中，整数是2个字节= 16位，它可以容纳的最大值是2 ^ 16-1 = 65535 2 ^ 16 = 65536

0％65536 = 0 -1％65536 = 65535对应于1111 ......... 1，并且所有位都设置为1（如果考虑残基类别为65536，则为0）直截了当。

我猜

不，如果您考虑这个概念，那么它是无符号整数的理想选择，它实际上可以解决

只需检查以下程序片段

int main（）{

unsigned int a=2;

cout<<(unsigned int)pow(double(a),double(sizeof(a)*8));

unsigned int b=-1;

cout<<"\n"<<b;

getchar();

return 0;

}

b = 4294967295的答案是4字节整数上的-1％2 ^ 32

因此对于无符号整数是完全有效的

如有任何差异，请报告