replacement of getch()

>i just want to whether there is a replacement for getch() in C++.
There isn't a standard equivalent for getch in either C or C++.

>my friend said getch() is C function.
No, getch is a compiler extension. You can use it in either C or C++ if your compiler supports it, but for the most part you don't need to.

For what purpose were you intending to use getch? The most common by far is keeping a console window from closing when you run the program from a Windows IDE:
That's not a recommended solution, and most experienced programmers will recommend that you use cin.get:

Okay, I have to say that i often use getch() not just to halt the console window.
I used getch() along with kbhit() [to get the key if pressed any]--very important use of getch().
And there are times when I have given the user to choose from a number of options (menu items) and used getch() to get the choice. I know the latter can be done with any input functions but getch() makes it simpler-- scanf(), cin and cin.get() will show the keys as u type in and then u have to press enter, whereas in getch() u just press the key and it's not even shown. getch() also makes things easier as u can enter only one key and there's no chance of receiving any degenerate inputs. On the otherhand it's very common for scanf(), cin and cin.get() to mess up with the inputs when only one keystroke is sufficient and desireable.

i would really love to know if there's any other way to get the functionality of getch()(i.e without using getch()) in the above mentioned cases.

i'm using getch() at password entering that display * when password is entered.

yes, i have used it for the same purpose for one of my programs too. I hope some one here will suggest how to work that out without using getch(), since according to "Narue" its a compiler extension and not a C function. Now we dont to code using something that is not part of the language.

The problem with unbuffered input is that it becomes the responsibility of the programmer to handle the buffering. Do you allow the user to make a typing mistake? Then handle the backspace. Then you can't have immediate response because you need an "enter" for a 'final' answer. Then you're back where you started with the standard way.

The reason it may 'work well' might be because other issues have been overlooked. It seems a more reasonable approach is to use standard functions that have already taken such issues into account and move forward. Yet this opinion is revisited thousands of times every year by programmers. Their first goal seems to be clearing the screen. Frankly, if the command shell commands behaved this way, I'd be pretty annoyed: execute two 'dir' commands consecutively, and the second throws away the result of the first -- annoying.

Ah well, it seems new programmers always must go full circle. I do try to get them to go the right way first, otherwise it seems to be a much longer journey.

That said, any nonstandard function has the implied disclaimer, "use at your own risk"! :p

Try
#include <iostream.h>
void main()
{ ...... /* your program here */
cin.get();
}

It should work .

>It should work
No, it should do whatever the hell it wants because you've invoked undefined behavior. And even when the undefined behavior is something intelligent, iostream.h is a nonstandard header, so you can't be sure that cin.get() even exists, much less that it does what you want it to.

To anyone reading this thread:
getch() is still available in the conio.h header file (at least in MinGW). cin.get() acts the same as getchar() - it echos the pressed key and waits for enter to be pressed.

And don't worry, Narue is wrong - iostream is very standard for C++.

>To anyone reading this thread:
You realize the thread is over three years old, yes?

>getch() is still available in the conio.h header file (at least in MinGW).
I'm sure it works just fine on your compiler, but because it's non-standard, that means it's not guaranteed to work on my compiler, or someone else's compiler. Is this that difficult of a concept for you people to grasp?

>cin.get() acts the same as getchar() - it echos the
>pressed key and waits for enter to be pressed.
Assuming that's what getchar does. getchar makes a call to a system function that performs the actual read, and that system function (whatever it may be) isn't required by the C++ standard to provide cooked input. However, I'll give this to you because I can't think of any systems off the top of my head that don't buffer up to a line feed. It's a safe assumption.

>And don't worry, Narue is wrong
Narue is always right[1]. You'd do well to realize that before truly embarrassing yourself.

>iostream is very standard for C++.
<iostream> is standard, <iostream.h> is not. Once again, this is a very simple concept, but I'll assume that you're just having trouble with reading for comprehension and missed the ".h" part.


[1] I'll qualify this. Narue is always right when it comes to the likes of you. I do make mistakes, but I get the strong impression that you're not a strong enough programmer to notice them or accurately correct me even if you do.