2

2012/11/13 Update: I found my question had already been asked. Here is a good solution for handling different line ending text files: Getting std :: ifstream to handle LF, CR, and CRLF?

Is it possible to contribute to libstdc++? How?


2012/11/11

I found there's something wrong with cout.
If there are two strings returned from getline(),
the second string will overwrite the first one in the output.

This is sample code:

#include<iostream>
#include<fstream>
using namespace std;

int main()
{
    //normal code
    cout << "Normal result:" << endl;
    string str1 = "hello";
    cout << str1;
    str1 = "123";
    cout << str1;

    cout << endl;

    //broken code
    cout << "Bug?" << endl;
    ifstream fin;
    fin.open("test.dat");

    string str;

    getline(fin, str);
    cout << str;

    getline(fin, str);
    cout << str;

    fin.close();
    return 0;
}

And here is the input file (test.dat):

hello
123

The output will be:

Normal result:
hello123
Bug?
123lo

I'm using ubuntu 12.10 64-bit,
and the version of compiler is g++ (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2.
Any advice? Is there anyone tell me where to file a bug?

Community
  • 1
  • 1
EriCSN
  • 48
  • 6
  • Update: Maybe it's not a bug but an enhancement. Is there anyone can tell me where to file this issue? Is it ok to post on Bugzilla? – EriCSN Nov 12 '12 at 23:44

1 Answers1

3

More likely than a bug in libstdc++ (which can occur, as well as in gcc, but are rather rare these days), there is incorrect line termination in your input file - likely it is using the DOS/Windows CR+LF line endings, which - as getline() discards the LF - results in the second string written over the first one. You can easily see this, if you run output of your program through some kind of hex-dumper, e.g. xxd.

Either check for \r at the end of the strings you read (btw, MacOS to version 9 used just this as the EOL marker), fix your input, or duly add new-lines to output, when printing.

peterph
  • 980
  • 6
  • 11
  • I got it. Thanks a lot! I forgot that I set CR+LF mode for my text editor Geany before. I will check that. – EriCSN Nov 12 '12 at 12:49
  • I rewrote my input file in LF mode and the code works. But I wondered why my text editor can recognize those different line endings when the compiler doesn't? :( – EriCSN Nov 12 '12 at 23:52
  • C++ uses `\n` as line delimiters, text editors try to guess what to use (for new file they use system default, for existing they check the first line ending usually). – peterph Nov 13 '12 at 15:52
  • @peterph I think it's time to break the rule. Is there anyone know where to file this issue? – EriCSN Nov 14 '12 at 13:50
  • @EriCSN If you want to complain about `'\n'` being the line terminator, I guess you'd have to file a complaint with the C++ standardization committee [see Wikipedia](http://en.wikipedia.org/wiki/ISO/IEC_JTC1/SC22). I'm not sure you'll have much success, though. – peterph Nov 14 '12 at 15:36
  • Me too. I guess so... lol Despite of those standard rules, is there any chance to make the compiler accept that workaround? The fact is that there are three different types of line endings. What's more, we have more chances to handle text files from different platform nowdays. I wish the compiler has the ability to handle those line endings. – EriCSN Nov 15 '12 at 14:03
  • This is actually hard-wired into the standard C++ library. So theoretically, you could patch it and recompile it, but that's hardly the way you want to do it. I would rather suggest converting the files prior to using them - it doesn't make much sense to implement the same magic the editors use. Actually, in case you are sticking to reasonable systems, the end-of-line will always contain `'\n'`, so the only thing you need is to get rid of the `'\r'` at the beginning or end of your lines, once you read them. – peterph Nov 15 '12 at 14:35
  • @peterph The answer is really helpful for me. It makes everything seems very simple and effective. Maybe I just thought too much... Thanks a lot! – EriCSN Nov 15 '12 at 16:22