getline(cin, string) issue

[jacqu35]

So I've been working on making a simple word game, but I've run into a snag. I programmed around it, but I would like to know why it is happening and can't find anything.

Here is the code:

int main()
{
        DWORD id; 
	string enter;
	string enter1;
	rules();			//function that shows user the rule of game
	getline(cin, enter);		//waits for user to push enter before creating the new thread
	CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) process, NULL, 0, &id); //makes new thread

	while(1)
	{
		box_maker();		//function that makes a box of letters for the user to see
		killthread = false;	//starts the other thread 
		cout << "You have 3 minutes as of now so start guessing.n" << endl;
		cout << line1show << "nn" << line2show << "nn" << line3show << "nn" << line4show << "nn" << line5show << endl;

		Sleep(180*1000);		//makes main sleep while other thread is running
		killthread = true;	//stops other thread
		
		cout << "Time's up." << endl;
		if(score > score_check)
		{
			cout << "Congratulations! You got a high score!" << endl;
			score_check = score;
		}
		cout << "Your score is: " << score << "." << endl;
		cout << "Press Ctrl+C if you would like to quit. Otherwise, hit enter twice if you would like to continue." << endl; //programming around the getline issue
		getline(cin, enter1);
	}
	return 0;
}

The following code all works like I expect until it gets to the second getline.
The user has to hit enter twice for the while loop to reiterate.
So my question is: Is there anything to getline that would make it ignore the user's first enter press or there something wrong with my code?

[Computergeek01]

Can we see the loopback function for your new thread? If it's expecting user input or something crazy that might do it.

[Zhuge]

Do you happen to use cin>> anywhere else in the program? That extraction operators will leave unused whitespace (including newlines) in the buffer, whereas getline() will remove that terminating character.

[jacqu35]

No I only use getline() throughout the whole program.

I just thought of something. I read from one text file that is my dictionary to see if they entered an actual word though I use getline for it too.

I also write to another text file to keep track of the words they've guessed though that shouldn't affect the buffer should it?


I can give you the new thread but it's like 250 lines of code that isn't too well organized since I never meant for this to be anything but a fun little project for myself.

[hanst99]

I also write to another text file to keep track of the words they've guessed though that shouldn't affect the buffer should it?

It's not the buffer, you are talking about completely distinct buffers here. So no, that shouldn't affect anything. Worry only about the things you do to cin here.

[Computergeek01]

Ok instead of posting 250+ lines of code, how about just checking your thread for any place it might be expecting user input; even if you're using "getchar()" to pause execution.

[jacqu35]

This is really weird.
In case it might help someone I just replaced the second getline with a system("pause") function.

When it gets to the pause, the program says "Press any key to continue . . ."
I press enter and it creates a newline with nothing else happening.
I press enter again and the program starts again.

(I don't know if that's how system("pause") is supposed to work, but I assume it is supposed to only require one enter key.)

[Computergeek01]

Well you do have an infinate loop going on with the "while(1)" at line 11.

EDIT: Also, this makes me think that your thread is the problem again. Have you looked it over again?

[jacqu35]

I want the program to start again hence the while(1) but I didn't know if you needed to press enter twice.

It definitely has to be my other thread. I put another getline() before the thread is created and that works perfectly too.

I will go try and find why my other thread is causing it to do that. I just wanted to make sure it wasn't anything specifically with getline() that would cause it to do that. Thanks for the responses.