此最小程序使用boost::program_options
来解析stringstream
。奇怪的是,解析后,流不再处于“良好”状态,并且设置了故障位和eofbit。
#include <iostream>
#include <sstream>
#include <boost/program_options/options_description.hpp>
#include <boost/program_options/parsers.hpp>
#include <boost/program_options/variables_map.hpp>
void test_stream(std::stringstream& s);
int main()
{
using namespace std;
namespace po = boost::program_options;
stringstream s;
s << "seed=3" << '\n';
test_stream(s);
po::options_description desc("");
desc.add_options()
("seed", po::value<int>());
po::variables_map vm;
po::store(po::parse_config_file(s, desc, true), vm);
po::notify(vm);
test_stream(s);
return 0;
}
void test_stream(std::stringstream& s)
{
using namespace std;
if (s.good())
{
cout << "stream is good" << endl;
}
else
{
cout << "stream is not good" << endl;
if (s.rdstate() & ios_base::badbit)
cout << "badbit is set" << endl;
if (s.rdstate() & ios_base::failbit)
cout << "failbit is set" << endl;
if (s.rdstate() & ios_base::eofbit)
cout << "eofbit is set" << endl;
}
}
输出:
stream is good
stream is not good
failbit is set
eofbit is set
尽管以某种方式预期到eof条件,但由于解析器可能已经读取了流,直到EOF,为什么还要设置故障位?
答案 0 :(得分:2)
根据ios::eof
标志的文档,在某些情况下可能会发生这种情况:
尝试在文件末尾读取的操作失败,因此eofbit和failbit最终都置位。此功能可用于检查失败是由于到达文件末尾还是其他原因。
Boost的解析器在流上使用2004/2004
和迭代器来提取选项。正如Jerry Coffin's answer中针对另一个问题所指出的,迭代器从序列中读取项目。读完最后一个后,序列的mv 2004/2004 "2004/(2004)"
位将被置位。当迭代器再增加一次以获得流结束迭代器时(这是将循环留在std::copy()
中的条件),它将尝试再次读取,因此流的eof
位也被置位