cin.getline and cin behave strangely. Problem with buffer?

Dec 15, 2012 at 5:41pm
Hello, i am messing around with operations on strings using pointers (i am not sure about translation. I mean char*). I recreated strcpy without problem. It works great, without any bugs, The "form" asking about strings looks like this:

1
2
3
4
5
6
7
8
char s1[10], s2[40];
cout << "First string "; 
cin.getline(s1,10);
cout << "Second string ";
cin.getline(s2,40);
m_strcpy(s2,s1)     // my strcpy, it works great
cout<<"New string: " << s2;
getch();



First string First
Second string Second
New string Firstd


It is actually a function implemented in bigger program, which let me choose (using arrow keys and enter), what operation i want to do at the moment. I can enter this function as many times as i want, it works perfectly. However, there is other function, that works terrible. Firstly, this is how it looks:

1
2
3
4
5
6
7
8
9
10
11
char s1[10]={' '}, s2[40]={' '};    //this initializing prevents errors occuring, when new string is longer than second
unsigned bit;
cout << "First string "; 
cin.getline(s1,10);
cout << "Second string ";
cin.getline(s2,40);
cout << "From which char should i start? "
cin << bit;
m_strpcpy(s2,ls1,bit)     // my strpcpy, it starts copying after (p-1)th char
cout<<"New string: " << s2;
getch();


Output after first running:
First string First
Second string Second
From which char should i start? 3
New string SeFirst


And then, if i run this function another time (simply by pressing enter once, becouse this option is highlighted in menu after function ends) output looks like:

First string
Second string Whatever
From which char should i start? 20
New string Whatever


It's like there are leftovers in buffer. This damn "\n" char, which automatically confirm cin.getline. I'm going to add, that, when i launch first function after launching second, it also crashes. On the other hand, if i launch second, after i had launch first, it works great. I was trying to add cin.ignore(), cin.ignore(INT_MAX,'\n') in few different places, but it ain't the way. In described situations, program works normally, so cin.ignore is not the anwser...
Dec 15, 2012 at 6:05pm
Looks like your strcpy function does not set the null terminator correctly.
Dec 15, 2012 at 6:20pm
Do you mean the second (strpcpy) function? It sees everything correctly. The problem might be cin >> bit line. When i replaced it with bit = 3, it worked great. Is there a problem with cin then?
Dec 15, 2012 at 6:28pm
I think that was a reference to this,
New string Firstd
where instead of the null terminator for string "first", there is instead the character 'd'.

As to the cin problem, this may help:
http://www.cplusplus.com/forum/beginner/88034/#msg473039
Dec 16, 2012 at 12:07pm
Chervil, i send thanks to you and bless your family :) It should be like this:
1
2
	cin >> bit;
	cin.sync();

Could you explain me, why is this happening with cin, and not with cin.getline? I would like to know the difference between them. I know, that cin reads until it sees blank sign (i don't know, if it is correct name. I mean space or newline) and cin.getline reads until it meets newline. So, i suspect that cin.getline reads also this newline sign, when cin ignores it and leave it in buffer, right?
Last edited on Dec 16, 2012 at 2:17pm
Topic archived. No new replies allowed.