cin.ignore(cin.rdbuf()->in_avail(),'\n');
There's no guarantee that in_avail() will give you a meaningful value. In fact, GCC always returns 0 by default. The correct way to use ignore() would be asking for up to the maximum possible stream buffer size:
cin.ignore(numeric_limits<streamsize>::max(), '\n');
There's a sticky that highlights all of the issues and potential solutions. You should read it.
deceptikon
Challenge Accepted
3,457 posts since Jan 2012
Reputation Points: 822
Solved Threads: 474
Skill Endorsements: 57
Did you try ignoring the \r as well?
That accomplishes nothing. Regardless of the newline configuration on the system, it will be appropriately converted by the standard I/O library such that the only thing you ever see is '\n'.
On Unix it's a non-issue anyway because '\n' is the native newline configuration to begin with. Other systems like Windows (which uses CRLF or "\r\n") and old Mac OS prior to version 10 (which uses '\r') do a little more work.
As an example of how the standard library works, here's a buffer filling routine that does newline compaction for text mode streams on Windows (starting at line 965). It's for the C standard library, but C++ does something similar way under the hood. ;)
deceptikon
Challenge Accepted
3,457 posts since Jan 2012
Reputation Points: 822
Solved Threads: 474
Skill Endorsements: 57
then what's the workaround for unix?
Workaround for what?
As concerns the original problem, I'm all but convinced that it's due to in_avail() being completely unreliable for the purpose of flushing the input buffer. The workaround in that case would be to use the correct solution in the first place, which I highlighted in my first reply. ;)
deceptikon
Challenge Accepted
3,457 posts since Jan 2012
Reputation Points: 822
Solved Threads: 474
Skill Endorsements: 57