Clearing cin's buffer

[IWishIKnew]

Since this is a newbie question (though I am not a newb), I am posting this here.

I have tried:

cin.rdbuf()->in_avail();
Upon further inspection of the source code, I saw that this actually did nothing at all (except return the number of characters available to be immediately read)

while(cin.rdbuff()->in_avail()) cin.get();
Theoretically should work, but, for some reason, does not... it should get a character while there are characters to be read, but when there is a character to be read (such as a multi-byte character) it will return 0 (I tested this one thoroughly... couldn't understand it!)

cin.clear()
read about this one, but documentation reveals that it doesn't even touch the buffer (has nothing to do with it!), even though it's been suggested... (scary...)

Anyway... I don't want to read until a '\n' or EOF (i tried EOF too, doesn't work). There must be some way to tell how many characters are available for reading in the buffer. The only way I;ve been able to erase the buffer so far, is by making API calls to set input to un-buffered, and then buffered. I would rather not have to do that.

Would this work, though:

//I would make the value of the buffer equal to the empty buffer of a stringstream

std::stringstream ss;
(*(cin.rdbuf())) = (*(ss.rdbuf())); //set cin's buffer to that of an 'empty' one 

I don't have the time to test it (school and all) but I would like to know.

If there is another (better) way to do this, I would also like to know about that.

[Cubbi]

If by "clearing cin's buffer" you mean clearing the input buffer of your console I/O subsystem, then the only way is indeed either "read until a '\n'" or "making API calls"

As for the C++ library object std::cin, it is unbuffered by default, because it guarantees that you can use std::cin.get() and std::getchar() interchangeably.

Now if you unsynchronize them, in_avail (and therefore readsome) begins working where the library implementors cared enough to make it work:

#include <iostream>
#include <string>

int main()
{
    std::cin.sync_with_stdio(false);

    std::cout << "Enter an integer followed by some garbage, please\n";
    int n;
    std::cin >> n;

    std::cin.ignore(std::cin.rdbuf()->in_avail());

    std::cout << "Now enter something else\n";
    std::string line;
    std::getline(std::cin, line);
    std::cout << "line = '" << line << "'\n";
}

Oracle/libCstd

Enter an integer followed by some garbage, please
123 garbage
Now enter something else
works in Oracle
line = 'works in Oracle'

Oracle/stlport4

Enter an integer followed by some garbage, please
123 garbage
Now enter something else
works in STLport4
line = 'works in STLport4'

IBM XL C++

Enter an integer followed by some garbage, please
123 garbage
Now enter something else
works in XLC
line = 'works in XLC'

clang/libc++:

Enter an integer followed by some garbage, please
123 garbage
Now enter something else
line = ' garbage'

their std::cin is always unbuffered: http://llvm.org/svn/llvm-project/libcxx/trunk/include/__std_stream

g++/libstdc++:
after replacing my cin.ignore by a cin.readsome or by your original loop,
while(std::cin.rdbuf()->in_avail()) std::cin.get();

Enter an integer followed by some garbage, please
123 garbage
Now enter something else
works in g++ but only if you get() in a loop
line = 'works in g++ but only if you get() in a loop'

the gcc weirdness is a known bug in istream::ignore: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857

Could someone run it by Visual Studio?

[JLBorges]

> Could someone run it by Visual Studio?

Enter an integer followed by some garbage, please
72 garbage
Now enter something else
Works with the Microsoft implementation
line = 'Works with the Microsoft implementation'

[IWishIKnew]

wow... sounds like a serious issue that should be fixed...

[SorinAlex]

try while(_kbhit()) _getch();

ps: you also need to include conio.h for that .

[IWishIKnew]

@SorinAlex
While that does clear cin's buffer, that's not what I was talking about. If you don't know how to operate on basic_istream<CharT, Traits> please don't answer.

Also, I use Linux, so I ask you to please refrain from making assumptions.