直观地说,从C ++规范来看,它看起来好像istream::putback( c )
应始终排列输入缓冲区,以便下一次调用istream::peek()
时应该读取字符c
。这不正确吗?我问,因为随Xcode 4.6发布的最新版本的libc ++似乎并未在所有情况下强制执行此行为 - 特别是当最后一个字符位于EOF时。如果您使用unget()
代替putback( c )
,情况也是如此。
libc ++的行为是正确的,还是我对putback()/unget()
如何正确运作的直觉?
考虑这个示例代码,它与libstdc ++一起使用但不与libc ++一起使用(断言失败)。
#include <sstream>
#include <cassert>
int main(int argc, const char * argv[])
{
std::istringstream in( "[Test]" );
while( in )
{
int c = in.get();
if( c == ']' )
{
in.putback( c );
assert( in.peek() == c ); // Fails with libc++. Succeeds with libstdc++.
break;
}
}
return 0;
}
答案 0 :(得分:6)
C ++ 11中的putback
函数实际上已经发生了变化:
§27.7.2.3/ 34
basic_istream<charT,traits>& putback(char_type c);
效果:表现为无格式输入函数(如27.7.2.3第1段所述),但函数首先清除
eofbit
。 ...
句子的后半部分在C ++ 03中不存在。
所以它可能取决于编译器是否已完全实现此更改,或者您是否使用了所需的选项(-std=C++11
?)。
答案 1 :(得分:4)
Bo Persson对标准是正确的。您可能正在使用旧版本的libc ++(您的问题出在LLVM错误跟踪器中,请参阅下文)。
更改已在修订版162108中引入:
--- istream (revision 162607)
+++ istream (revision 162608)
@@ -1263,6 +1263,7 @@
try
{
#endif // _LIBCPP_NO_EXCEPTIONS
+ this->clear(this->rdstate() & ~ios_base::eofbit);
sentry __sen(*this, true);
if (__sen)
{
有关变更的日志:
$ svn log -r 162608
----------------------------------------------- ------------------------- r162608 | hhinnant | 2012-08-25 00:03:03 +0200(星期六,2012年8月25日)| 1 线
有basic_istream搜索,回放并取消首先明确的eofbit。修复 http://llvm.org/bugs/show_bug.cgi?id=13089