stringstream 无符号转换损坏？

Question

考虑这个程序：

#include <iostream>
#include <string>
#include <sstream>
#include <cassert>

int main()
{
    std::istringstream stream( "-1" );
    unsigned short n = 0;
    stream >> n;
    assert( stream.fail() && n == 0 );
    std::cout << "can't convert -1 to unsigned short" << std::endl;
    return 0;
}

我在 OS X 10.5.6 上的 gcc（版本 4.0.1 Apple Inc. build 5490）上尝试过这个程序，断言是正确的； 它无法将 -1 转换为无符号短整型。

然而，在 Visual Studio 2005（和 2008）中，断言失败，n 的结果值与编译器生成的隐式转换所期望的值相同 - 即“-1”是 65535，“-2”是 65534 等但随后“-32769”转换为 32767 就变得很奇怪。

这里谁是对的，谁是错的？ （-32769 到底是怎么回事？？）

Answer 1

GCC 在 Max Lybbert 的帖子中声称的行为基于 C++ 标准中的表格，这些表格将 iostream 行为映射到 printf/scanf 转换器（或者至少是我读到的）。 然而，g++的scanf行为似乎与istream行为不同：

#include <iostream>
#include <cstdio>
using namespace std;;

int main()
{
    unsigned short n = 0;
    if ( ! sscanf( "-1", "%hu", &n ) ) {
        cout << "conversion failed\n";
    }
    else {
        cout << n << endl;
    }
}

实际上打印65535。

Answer 2

首先，将字符串“-1”读取为负数取决于区域设置（区域设置可以通过将负数括在括号中来识别负数）。 您的默认标准是“经典”C 语言环境：

到目前为止，区域设置的主要用途是在流 I/O 中隐式使用。 每个istream和ostream都有自己的区域设置。 默认情况下，流的区域设置是创建流时的全局区域（第6页）。 ...

最初，全局语言环境是标准 C 语言环境，locale::classic()（第 11 页）。

根据 GCC 人员的说法，允许数字溢出流输入操作失败（谈论溢出有符号整数的负数）：

[T]libstdc++-v3 的行为严格符合标准。 ...当尝试读取时，它不适合有符号的 int i，并且失败。

感谢另一个答案，已提交错误并且此行为已更改：

哎呀，显然我们从未正确解析无符号负值。 这
修复很简单。 ...

已在主线中修复，也将在 4.4.1 中修复。

其次，虽然整数溢出通常是可以预测的，但我相信它是 官方未定义的行为，所以虽然我不能说出为什么 -32769” 转换为 32767，但我认为这是允许的。

Answer 3

试试这个代码：

#include <iostream>
#include <string>
#include <sstream>
#include <cassert>

int main()
{
    std::istringstream stream( "-1" );
    std::cout << "flags: " << (unsigned long)stream.flags() << std::endl;
    return 0;
}

我在我的 VS2005 上尝试过这个：

flags: 513

在 codepad.org （我认为它使用 g++）上给出：

flags: 4098

这告诉我 gcc 使用不同的默认 fmtflags。 由于 fmtflags 控制可能的转换，因此您会得到不同的结果。