简体   繁体   English

C ++ cin数字忽略第一行?

[英]C++ cin numbers ignores first line?

I've run into a really strange issue. 我遇到了一个非常奇怪的问题。 I can reproduce on my win7 laptop as well as an ubuntu machine. 我可以在win7笔记本电脑和ubuntu机器上进行复制。

I have a C++ program like so: 我有一个这样的C ++程序:

#include <string>
#include <sstream>
#include <iostream>
using namespace std;

int main() {
  for (int i = 0; i < 9; i++) {
    string line;
    getline(cin, line);
    stringstream ss(line);

    for (int j = 0; j < 9; j++) {
      int p = 8;
      ss >> p;
      cout << p;
    }
    cout << endl;
  }
  return 0;
}

Now, if i compile it an run it with ./a.out < test.txt where text.txt contains: 现在,如果我编译它,请使用./a.out < test.txt运行它,其中text.txt包含:

1 2 3 4 5 6 7 8 9
2 2 3 4 5 6 7 8 9
3 2 3 4 5 6 7 8 9
4 2 3 4 5 6 7 8 9
5 2 3 4 5 6 7 8 9
6 2 3 4 5 6 7 8 9
7 2 3 4 5 6 7 8 9
8 2 3 4 5 6 7 8 9
9 2 3 4 5 6 7 8 9

It will output (without spaces): 它将输出(无空格):

8 8 8 8 8 8 8 8 8
2 2 3 4 5 6 7 8 9
3 2 3 4 5 6 7 8 9
4 2 3 4 5 6 7 8 9
5 2 3 4 5 6 7 8 9
6 2 3 4 5 6 7 8 9
7 2 3 4 5 6 7 8 9
8 2 3 4 5 6 7 8 9
9 2 3 4 5 6 7 8 9

Why is the first line wrong? 为什么第一行错了? I've tried reading the first line out of the loop as well. 我也尝试过从循环中读取第一行。 Also, if I replace ss > p with cin > p I just get an output table full of 8's. 另外,如果我用cin > p替换ss > p ,那么我得到的输出表全是8。

This is not making any sense!! 这没有任何意义!

Okay you guys were right. 好的,你们是对的。 Some weird stuff as the first character of my input file: 一些奇怪的东西作为我的输入文件的第一个字符:

od -c test.txt
0000000 357 273 277   2       0       5       0       0       7       0
0000020       0       6  \n   4       0       0       9       6       0
0000040       0       2       0  \n   0       0       0       0       8

It's a problem with the data (since the code looks OK). 数据有问题(因为代码看起来不错)。 Most probably you've saved your text file with UTF-8 encoding with BOM. 您很可能已使用带有BOM的UTF-8编码保存了文本文件。 An UTF-8 BOM is three bytes at the start of the file, and trying to interpret those as a decimal number specification would fail. UTF-8 BOM在文件的开头是三个字节,尝试将其解释为十进制数指定将失败。

Second, third, fourth line etc. OK because you're creating new istringstream object for each line, so not retaining error mode from previous line. 第二,第三,第四行等。确定,因为您正在为每一行创建新的istringstream对象,所以不要保留上一行的错误模式。

So, fix: save the file without BOM -- assuming the BOM hypothesis is correct. 因此,修复:假设没有BOM,则保存文件-假设BOM假设正确。

Cheers & hth., 干杯,……

您的代码对我来说似乎很好,如果您是我,则将仔细检查输入文件:您确定第一行没有空的第一行或某些非数字字符吗?

I suspect you wrote your own getline() , and the bug is there. 我怀疑您编写了自己的getline() ,该错误在那里。 InputStreams have a getline(char*, int) , and I suspect your cramming string.begin() into the first param, and Some Other Number into the latter. InputStreams有一个getline(char*, int) ,我怀疑您在第一个参数中string.begin() ,而在后面的参数中包含了Some Other Number。

Don't do that. 不要那样做

All your program should be doing is copying the input to the output (given this code and that input). 程序应该做的就是将输入复制到输出中(给出此代码和输入)。 It's not doing that either, even on the lines that "work". 即使在“有效”的线路上也没有这样做。

I am seeing a number of Not So Experienced Programmer 'signatures' here. 我在这里看到了许多经验不足的程序员的“签名”。 1) Overly short variable names (outside a for loop counter), "ss" and "p" 2) Magic error number (8), particularly one that doesn't stand out from the data. 1)变量名过短(在for循环计数器之外),“ ss”和“ p” 2)魔术错误号(8),尤其是不能从数据中脱颖而出的错误号。 3) "using" 3)“使用”

1 and 3 both hint at a lack of typing speed, and therefore experience... despite your 1k+ reputation (which is based mostly on asking questions... the situation becomes clearer). 1和3都暗示着打字速度不足,因此经验不足……尽管您的声誉超过1k(这主要是基于提问……情况变得更加清晰)。

I'd rewrite it something like this: 我会这样重写它:

int curDig;
curLine >> curDig;
if (curLine.good()) {
  cout << curDig;
} else {
  cout << "FAILED at line: " << lineIdx << " containing: " << line << std::endl;
}

Chances are, you're going to see "FAILED at line: 0 containing: " right out of the gate, due to what I think is a bug in your getline() . 很有可能,由于我认为getline()的错误,您很快就会看到“ Failed at line:0 included:”。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM