I was debugging my code because a strange, out-of-place request for input was showing up, before my real getline.
Upon closer inspection, I lost track of the yellow debug pointer right after stepping over this line of code:
std::string user_input;
// get the response
do {
// OPEN CIN GUARD
reset_cin();
} while (!(std::getline(std::cin, user_input)));
reset_cin();
// EXIT CIN GUARD
2. Entering the reset_cin() function where the "mysterious" input request happens. If I step over cin.ignore, I get the request, but the debugger does not indicate exactly which line of code caused that - the yellow debug pointer that shows the current code is nowhere to be seen.
3. While the program was still on (waiting for input), I checked getline() to make sure it's not responsible for the request. The yellow debug pointer was still missing. After hitting ENTER debug finally moved to getline() - but from where?
How many times do you think calling ignore() is necessary? You do realize that if you call ignore() when the delimiter is not in the stream it will wait until the delimiter appears?
I'd start by rearranging your loop to use a while() loop instead of the do while.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
...
while(!getline(std::cin, user_input))
{
reset_stream(std::cin);
}
...
// This can now be used to "clear" any input stream not just cin.
std::istream& reset_stream(std::istream& sin)
{
sin.clear();
sin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
return sin;
}
I wouldn't put a reset() before or after the loop. If you have problems before the loop you should find the source of the problem and take care of the problem there instead of trying to anticipate every problem after the fact. By the way getline() extracts the delimiter from the stream and discards it. By default the delimiter is the new line character so if getline() succeeds there will be no new line in the stream to worry about.