下面的代码片段从 std::cin 读取三个整数;它将两个写入 numbers
并丢弃第三个:
std::vector<int> numbers(2);
copy_n(std::istream_iterator<int>(std::cin), 2, numbers.begin());
我希望代码从 std::cin
中读取两个整数,但事实证明这是正确的,符合标准的行为。这是标准中的疏忽吗?这种行为的理由是什么?
从 C++03 标准中的 24.5.1/1 开始:
构建完成后,每个
使用 time ++ 时,迭代器读取
并存储值T
。
因此,在上面的代码中,在调用时流迭代器已经读取了一个整数。从那时起,算法中迭代器的每次读取都是预读,产生前一次读取缓存的值。
下一个标准的最新草案 n3225 似乎没有任何变化这里(24.6.1/1)。
在相关说明中,当前标准的 24.5.1.1/2 参考 istream_iterator(istream_type& s)
构造函数读取
效果:初始化in_stream
s
。 value
可能会在期间初始化
施工或第一次
参考。
强调“值
可以被初始化......”而不是“应被初始化”。这听起来与 24.5.1/1 相矛盾,但也许这本身就值得一个问题。
The snippet below reads three integers from std::cin
; it writes two into numbers
and discards the third:
std::vector<int> numbers(2);
copy_n(std::istream_iterator<int>(std::cin), 2, numbers.begin());
I'd expect the code to read exactly two integers from std::cin
, but it turns out this is a correct, standard-conforming behaviour. Is this an oversight in the standard? What is the rationale for this behaviour?
From 24.5.1/1 in the C++03 standard:
After it is constructed, and every
time ++ is used, the iterator reads
and stores a value of T
.
So in the code above at the point of call the stream iterator already reads one integer. From that point onward every read by the iterator in the algorithm is a read-ahead, yielding the value cached from the previous read.
The latest draft of the next standard, n3225, doesn't seem to bear any change here (24.6.1/1).
On a related note, 24.5.1.1/2 of the current standard in reference to the istream_iterator(istream_type& s)
constructor reads
Effects: Initializes in_stream
with
s
. value
may be initialized during
construction or the first time it is
referenced.
With emphasis on "value
may be initialized ..." as opposed to "shall be initialized". This sounds contradicting with 24.5.1/1, but maybe that deserves a question of its own.
发布评论
评论(4)
不幸的是,copy_n 的实现者未能考虑复制循环中的预读。 Visual C++ 实现在 stringstream 和 std::cin 上都按照您的预期工作。我还检查了原始示例中 istream_iterator 是在线构造的情况。
下面是 STL 实现中的关键代码。
这是测试代码
Unfortunately the implementer of copy_n has failed to account for the read ahead in the copy loop. The Visual C++ implementation works as you expect on both stringstream and std::cin. I also checked the case from the original example where the istream_iterator is constructed in line.
Here is the key piece of code from the STL implementation.
Here is the test code
今天我遇到了非常相似的问题,这里是例子:
用 g++ 4.6.3 编译上面的例子会产生一个:
,用 g++ 4.7.2 编译会产生另一个结果:
c++11 标准告诉了这个关于
copy_n 的信息:
正如您所看到的,没有指定迭代器到底发生了什么,这意味着它依赖于实现。
我的观点是,您的示例不应读取第三个值,这意味着这是标准中的一个小缺陷,因为他们没有指定行为。
Today I encountered very similar problem, and here is the example:
Compiling the above example with g++ 4.6.3 produces one:
, and compiling with g++ 4.7.2 produces another result :
The c++11 standard tells this about
copy_n
:As you can see, it is not specified what exactly happens with the iterators, which means it is implementation dependent.
My opinion is that your example should not read the 3rd value, which means this is a small flaw in the standard that they haven't specified the behavior.
我不知道确切的理由,但由于迭代器还必须支持运算符 *(),因此它必须缓存它读取的值。允许迭代器在构造时缓存第一个值可以简化这一过程。当流最初为空时,它还有助于检测流结束。
也许您的用例是委员会没有考虑的一个?
I don't know the exact rationale, but as the iterator also has to support operator*(), it will have to cache the values it reads. Allowing the iterator to cache the first value at construction simplifies this. It also helps in detecting end-of-stream when the stream is initially empty.
Perhaps your use case is one the committee didn't consider?
今天,在你九年后的今天,我遇到了同样的问题,所以按照这个线程,在解决这个问题时注意到了这一点,似乎我们可以在第一次之后每次读取时将迭代器走一步(我的意思是
cin< /code> 也不能自动忽略换行符结尾,我们用 cin.ignore() 来帮助它,我猜我们也可以帮助这个实现):
并且应该产生如下输出:
Today, 9 years after you, I fell into the same problem, So following this thread, while playing with the problem noticed this, It seems we can walk the iterator one step for each reading after first time(I mean
cin
also can't ignore end of line feed automatically, we help it withcin.ignore()
, we can help this implementation too I guess):and that should produce output like: