getline returning entire file

[vckngs7]

Hello,

I've run into a situation where getline returns the entire file. I have not had the problem before and could not find a solution to this online. When I open my input file in textwrangler it reads the file correctly, with new lines at the end of each line. However, my call to getline returns the entire file instead of just the first line.

Any ideas of where I should look? Might it be the wrong kind of new line? Perhaps there is something about iostream that I do not understand?

Thanks.

[Volatile Pulse]

It's always possible that textwrangler will display the correct line endings where as something that actually shows you the line endings, like MSWord or Notepad++, will show you the true line endings. Also remember, word wrapping isn't actual line endings. However, stream objects don't differentiate between line endings, or else it wouldn't be portable, I believe.

Your code snippet and the text file may help to alleviate the issue, however, the line endings might change during a copy/paste. Another suggestion would be to try redownloading/retyping/copying to a new file the one that's having issues, also try using a file that you know is good and see if you have the same issues.

[vckngs7]

Your thinking was right along the lines of what I was thinking. Textwrangler has an option to show invisible characters which indicates that a line ending is indeed at the end of the line.

I have run the code with other files and it works fine. Are there only certain types of line endings which are pulled into the stream or which getline recognize?

The relevant code is the opening of a file and then a call to getline.

std::string buf;
getline(infile,buf);
cout << buf << endl;

the cout returns the entire file instead of just the first line for the file in question.

The file in question is a larger version of the following (with new lines at the end of each line of course)

label1,label2,...labeln
0,.43,...,0
.12,0,0
.
.
.
2.4,.6,0

[Chervil]

The file in question is a larger version of the following (with new lines at the end of each line of course)

But what sort of new-lines?

If you examine the file using a hex editor, you can see the exact character code used to represent the newline.

Or just open the file in binary mode, rather than text mode, and examine each character , to see what code is used to represent the newline.

[vckngs7]

Using Hex Fiend I'm getting 0A as the newline.

I'm using two different files and according to hex fiend they both contain the same new-line character.

[Volatile Pulse]

Ugh, this internet, I swear. Anyways, 0A translates to '\r', not '\n' as many people think. If the file originated from Windows and has DOS endings, the next character in the file should be '\n' or 0D. getline has a third parameter called the delimiter. You can specify the last character to read by passing a character. To more or less debug your code, try switching this to ',' or '\r'.

Another thought is that you have the code you pasted innocently wrapped inside of a loop of some sort, multiple calls to the same function, goto/labels, while/for loop, etc. I'd suggest sharing a few more lines with us so we can get to the bottom of this. Something is horribly amiss.

[Lowest0ne]

Unix line endings (0x0A) and Windows line endings (0x0A, 0x0D) work fine for me. Mac line endings (0x0D) do not.

I use Notepad++ to quickly switch between the three.

[Chervil]

http://www.asciitable.com/

Decimal Hex  Char Description
  10     A    NL   Line Feed, New Line
  13     D    CR   Carriage Return

The Windows newline in hex is 0D 0A, that is a CR-LF pair (carriage-return, linefeed) "\r\n".

Other OS use hex 0A, that is a single NL (line feed), '\n'.