I'm writing a small program for a class I am working on and I have a bit of code that is not functioning correctly. I've tried debugging but it isn't helping much.
The problem is in the function note1out(). The program completely skips over the getline command and doesn't wait for input from the user. As far as I can tell it should work fine but it doesn't. Can someone please analyze this little snippit and help me find out the problem. Let me know if you need more of the code.
P.S. The compiler is Dev C++.
ifstream note1 ("note1.txt");
while (!note1.eof() )
getline (note1, a);
cout << "The note reads: " << endl << a << endl << endl;
cout << "Begin re-writing the note... " << endl;
getline (cin, a);
ofstream note1 ("note1.txt");
note1 << a;
cout << "The note has been saved..." << endl;
Last edited by Vipervenom9; April 4th, 2010 at 04:15 PM.
Reason: Need code to be in code window.
The code is doing precisely what it should; it's simply that you're missing an aspect of what's happening.
Now, you haven't show it here, but I'll bet that somewhere prior to the note1out() call, you're using operator >> to extract something from cin. As usual, anything you enter on the console goes into the input stream, and typically you'll end an input by hitting return. This puts a newline into the input stream, of course.
However, operator>> doesn't read that newline, since operator>> stops when it encounters whitespace by default. If you only use operator>>, then this isn't a problem; the extra newline in the stream will be skipped on the next read (since >> skips whitespace).
But if you call >> and then you call getline(), you run into a tricky situation. getline() by default reads until it sees a newline. But there's already a newline in the stream from the preceeding operator>> usage. So getline() just finds it and returns immediately.
Now, you could call getline() twice, or you could use cin.ignore() to explicitly get rid of that extra newline. The trouble is.....it's only correct to do this between a >> and a getline(). Between two >> it won't really matter, but between two getline()s there's a good chance it won't do what you want. Which brings us to your code: You're calling getline() at the start of a function, which means you need to make sure that the last cin operator prior to the function call was *not* another getline(). Maybe your program is simple enough that this is an easy guarantee....maybe not.
One option you could do is to create a wrapper for cin (or any other istream) which imposes the desired behavior, but that's probably overkill in your case.
As you mentioned, my code is extremely simple. The most complex code I know is writing and reading files... lol. The most recent user input before these two functions was indeed a cin >> operator. The code was: cin >> notemainselect;
However, as for the current problem, using the cin.ignore(); command to flush that lingering value left in cin did indeed solve the problem... the code now functions correctly.
Thank you for your help. I would really like to know a little more about the issue though. It would help me clean up my bad coding habbits.
It works well enough. In my observation, though, once you get past the early lessons and toy programs, the frequency with which you take input from cin will decrease significantly in favor of input from files or network sockets; and, since you can be very specific when defining a file format, this sort of problem simply tends not to arise.
One pattern I like to use when parsing files is to read one line a time (always using getline()) and then parse the line further using an istringstream.
Last edited by Lindley; April 4th, 2010 at 05:10 PM.