缩小 C++0x 中的转换范围。是只有我这么认为，还是这听起来像是一个重大改变？

Question

C++0x 将使以下代码和类似代码格式错误，因为它需要从 double 到 int 的所谓窄化转换。

int a[] = { 1.0 };

我想知道这种初始化在现实世界的代码中是否经常使用。此更改会破坏多少代码？如果您的代码受到影响，需要付出很大的努力才能在代码中修复此问题吗？

---

有关参考，请参阅 n3225 的 8.5.4/6

缩小转换是隐式转换

• 从浮点类型到整数类型，或者
• 从long double到double或float，或者从double到float，除非源是常量表达式并且转换后的实际值在可以表示的值范围内（即使无法精确表示） ，或
• 从整数类型或无作用域枚举类型到浮点类型，除非源是常量表达式，并且转换后的实际值将适合目标类型，并且在转换回原始值时将产生原始值输入，或
• 从整数类型或无作用域枚举类型到无法表示原始类型的所有值的整数类型，除非源是常量表达式，并且转换后的实际值将适合目标类型并产生转换回原始类型时的原始值。

Answer 1

当我使用 GCC 时，我遇到了这个重大变化。编译器打印出如下代码的错误：

void foo(const unsigned long long &i)
{
    unsigned int a[2] = {i & 0xFFFFFFFF, i >> 32};
}

在函数void foo(const long long unsigned int&)中：

错误：(((long long unsigned int)i) & 4294967295ull)从long long unsigned int到unsigned int的缩小转换> 在 { } 内

错误：(((long long unsigned int)i) >> 32)从long long unsigned int到unsigned int<的缩小转换/code> 在 { }

内


幸运的是，错误消息很简单，修复也很简单：

void foo(const unsigned long long &i)
{
    unsigned int a[2] = {static_cast<unsigned int>(i & 0xFFFFFFFF),
            static_cast<unsigned int>(i >> 32)};
}

代码位于外部库中，仅在一个文件。我认为重大更改不会影响太多代码。新手可能获取 但很困惑。。

Answer 2

如果我发现我在过去 12 年中编写的任何 C++ 代码都存在此类问题，我会对自己感到惊讶和失望。但大多数编译器都会一直发出有关任何编译时“缩小”的警告，除非我遗漏了一些东西。

这些是否也会缩小转化范围？

unsigned short b[] = { -1, INT_MAX };

如果是这样，我认为它们可能比浮点类型到整数类型的示例更频繁地出现。

Answer 3

尝试将 -Wno-narrowing 添加到您的 CFLAGS，例如：

CFLAGS += -std=c++0x -Wno-narrowing

Answer 4

我遇到的一个实际例子：

float x = 4.2; // an input argument
float a[2] = {x-0.5, x+0.5};

数字文字隐式为 double ，这会导致提升。

Answer 5

如果有人遇到类似的情况，我不会感到惊讶：（

float ra[] = {0, CHAR_MAX, SHORT_MAX, INT_MAX, LONG_MAX};

在我的实现中，最后两个在转换回 int/long 时不会产生相同的结果，因此正在缩小）

我不记得了不过，写这个。仅当极限的近似值对某些事物有用时，它才有用。

这看起来至少也有点合理：

void some_function(int val1, int val2) {
    float asfloat[] = {val1, val2};    // not in C++0x
    double asdouble[] = {val1, val2};  // not in C++0x
    int asint[] = {val1, val2};        // OK
    // now do something with the arrays
}

但它并不完全令人信服，因为如果我知道我恰好有两个值，为什么要把它们放在数组中而不是仅仅 float floatval1 = val1, floatval1 = val2; ？不过，动机是什么，为什么应该编译（并且可以工作，前提是精度损失在程序可接受的精度范围内），而 float asfloat[] = {val1, val2}; 不应该？无论哪种方式，我都会从两个整数初始化两个浮点数，只是在一种情况下，这两个浮点数恰好是聚合的成员。

在非常量表达式导致缩小转换的情况下，即使（在特定实现上）源类型的所有值都可以在目标类型中表示并且可以转换回其原始值，这似乎特别严酷：

char i = something();
static_assert(CHAR_BIT == 8);
double ra[] = {i}; // how is this worse than using a constant value?

假设没有错误，大概修复方法始终是使转换显式化。除非您对宏做了一些奇怪的事情，否则我认为数组初始值设定项仅出现在接近数组类型的地方，或者至少出现在表示类型的地方，这可能依赖于模板参数。因此，即使比较冗长，转换也应该很容易。

Answer 6

缩小转换错误与隐式整数提升规则相互作用很差。

我的代码有一个错误，看起来像

struct char_t {
    char a;
}

void function(char c, char d) {
    char_t a = { c+d };
}

“产生缩小转换错误”（根据标准这是正确的）。原因是 c 和 d 隐式提升为 int 并且生成的 int 不允许缩小范围回到初始化列表中的 char。

OTOH

void function(char c, char d) {
    char a = c+d;
}

当然还可以（否则一切都会崩溃）。但令人惊讶的是，

template<char c, char d>
void function() {
    char_t a = { c+d };
}

如果 c 和 d 的总和小于 CHAR_MAX，则 Even 是可以的，并且编译时不会发出警告。我仍然认为这是 C++11 中的一个缺陷，但那里的人不这么认为 - 可能是因为如果不摆脱隐式整数转换（这是过去人们编写代码时的遗留物），就不容易修复就像 char a=b*c/d 一样，即使 (b*c) > CHAR_MAX) 也能正常工作，或者缩小转换错误（这可能是一件好事）。

Answer 7

这确实是一个重大变化，因为此功能的现实生活经验表明，由于将 C++03 代码库移植到 C++11 的现实生活中的痛苦，gcc 在许多情况下已将范围缩小为错误警告。请参阅gcc bug 报告中的此评论：

该标准仅要求“合格的实现应发出至少一条诊断消息”，因此允许编译带有警告的程序。正如 Andrew 所说，-Werror=narrowing 允许您根据需要将其设置为错误。

G++ 4.6 给出了一个错误，但在 4.7 中有意将其更改为警告，因为许多人（包括我自己）发现缩小转换是在尝试执行操作时最常遇到的问题之一。将大型 C++03 代码库编译为 C++11。以前格式良好的代码，例如 char c[] = { i, 0 }; （其中 i 只会在 char 的范围内）导致错误，必须更改为 char c[] = { (char)i, 0 }

Answer 8

看起来 GCC-4.7 不再给出缩小转换的错误，而是发出警告。