c++ - 可以从硬编码整数常量中删除 "LL"并替换为 "static_cast<uint64_t>(...)"吗?

标签 c++

我正在修改对硬编码常量使用“long long”( LL) 数据类型定义的遗留代码,如下所示:

0xFFFFFFFFFFFFFFFFLL

我相信 LL附加到常量保证该常量将被解释为 long long .

但是,我不想依赖long long在位数方面具有任何特定的依赖于编译器的解释。

因此,我希望我的变量声明没有 LL在常量中,而是使用:

uint64_t a = static_cast<uint64_t>(0xFFFFFFFFFFFFFFFF);

我想认为常量 0xFFFFFFFFFFFFFFFF在转换为 uint64_t 之前,编译器不会将其解释为 32 位整数,这将导致 a是包含值 0xFFFFFFFF 的 64 位整数, 而不是期望值。

(我目前感兴趣的 64 位编译器是 VS 2010 和 Ubuntu 12.04 LTS GCC。但是,我希望这段代码能够以任何现代编译器所需的方式运行。)

对于大多数或所有现代编译器,上面的代码是否会按预期工作,所以 a 的值是多少?根据需要,已正确设置为包含常量 0xFFFFFFFFFFFFFFFF 中的所有数字, 不包括 LL在常量的末尾?

(注意:在常量末尾包含 I64 会导致编译器错误。也许还有另一个标记需要(或可以)包含在常量末尾以告诉编译器将常量解释为64 位整数?)

(另外:也许 static_cast<uint64_t> 是不必要的,因为该变量被显式定义为 uint64_t?)

最佳答案

为了减少 Andy 所说的要点:如果实现具有一种或多种能够表示 0xFFFFFFFFFFFFFFFF 的标准整数类型,然后是文字 0xFFFFFFFFFFFFFFFF一个这些类型。

对你来说,哪一个并不重要,因为无论是哪一个,转换为 uint64_t 的结果都是是一样的。

如果(C++11 之前的)实现没有任何足够大的整数类型,则 (a) 程序格式错误,因此您应该进行诊断; (b) 它可能不会有uint64_t无论如何。

你是对的 static_cast是不必要的。它执行与分配给 uint64_t 相同的转换无论如何都会做。有时,强制转换会抑制针对某些隐式整数转换获得的编译器警告,但我认为在这种情况下,任何编译器都不太可能针对隐式转换发出警告。通常不会有一个,因为 0xFFFFFFFFFFFFFFFF通常会有类型 uint64_t已经。

顺便说一句,最好写成static_cast<uint64_t>(-1) , 或者只是 uint64_t a = -1; .它保证等于 0xFFFFFFFFFFFFFFFF , 但读者更容易看出 -1 之间的区别和 0xFFFFFFFFFFFFFFF不如看看0xFFFFFFFFFFFFFFFF之间的区别和 0xFFFFFFFFFFFFFFF .

关于c++ - 可以从硬编码整数常量中删除 "LL"并替换为 "static_cast<uint64_t>(...)"吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15769226/

相关文章:

竞赛博弈树的 C++ 实现

C++ 引用计数 : use a Macro to do it, 有什么优点?

c++ - 为什么首选异步IO

c++ - 二叉树类创建随机节点,打破

c++ - 为什么 const char *pt2= {'1' , '2' , '3' , '\0' };无法编译?

c++ - 如何检查鼠标是否在控件上

c++ - 指针:在 C++ 中不可赋值的表达式

c++ - 将 C++ 函数对象作为线程例程传递给 pthread_create 函数

c++ - 绕过显式特化的标准限制

c++ - 您对这个 C++ 表达式有什么期望?