About conio.h

[ninja01]

I know that conio.h is not c++ standard library nor a c standard library.

Do you know any information about the library like where it comes from and why it is not standardized. I asking this question because I used work with some of its functions.

Is there a standard library that provide the same functions as:
kbhit() and getch()?

[Peter87]

ninja01 wrote:

Do you know any information about the library like where it comes from and why it is not standardized.

I don't know much about the history except that some older compiler, Like Boorland C++, came with this header.

I think it was never standardized because the capabilities varied a lot between different machines and it's not even sure the standard input/output streams are connected to anything that the user can interact with directly. You can easily run your program so that input and/or output is instead connected to files.

Imagine I had the following program.

#include <iostream>

int main()
{
	int x;
	std::cin >> x;
	std::cout << (2 * x) << "\n";
}

On Linux, if the executable file is named "double" and I had a file named "input" containing only the content "24" and then I ran the program as

./double < input > output

then the input would get read from the "input" file and the output "48" would get stored in a file named "output". I would not see any output or get the chance to input anything. I believe something similar should work on Windows too.

Historically the standard library has been relatively small and a lot of the functionality has been left to system libraries or third-party libraries to provide. Nowadays more and more things get standardized, they even tried to put graphics into the standard library at one point, so if console applications had still been the norm I wouldn't have been too surprised if they had actually standardized something like this. But now I don't think it's going to happen.

Is there a standard library that provide the same functions as:
kbhit() and getch()?

There are "curses" libraries that you can use. On Linux and other unix-like systems it's common to use ncurses. On Windows I think you can use pdcurses. It should be possible to write code that is compatible with both ncurses and pdcurses. There is a getch() function. I don't think there is a kbhit() function but you can accomplish the same thing using other functions.

[ninja01]

On Linux, if the executable file is named "double" and I had a file named "input" containing only the content "24" and then I ran the program as

./double < input > output

then the input would get read from the "input" file and the output "48" would get stored in a file named "output". I would not see any output or get the chance to input anything. I believe something similar should work on Windows too.

I am so so interest about experimenting this, this is what I did

I put the code below in file named main.cpp

#include <iostream>

int main()
{
	int x;
	std::cin >> x;
	std::cout << (2 * x) << "\n";
}

Then I compiled it. with command

g++ main.cpp -o double.exe

. I have now double.exe

I put 24 in file named: input.txt

Then I run the command ./double <input> output. I got error for that. I am guessing either you use glang while I use gcc, or I did not understand what you just told(

[Peter87]

This has nothing to do with the compiler.

Doesn't the error message give a clue about what is wrong?

Not sure if it matters, but are you sure the input file is named "input" and not something else like "input.txt"? Note that Windows hides known file extensions by default.

[seeplus]

concio.h came from the original Borland c compilers and were adopted in some form or other by other compiler vendors. The one currently supplied by MS (and others) is a vastly cut-down version. The main functions now provided by conio.h are:
_getch(), _getche(), __ungetch(), _putch() and _kbhit(). _putch() writes without buffering.

Is there a standard library that provide the same functions

No. You need to use a 3rd party lib.

[ninja01]

The error is this:

The system cannot find the file specified

and yes the input is input.txt, itself and double.exe are both in the same directory d:/

[Peter87]

So did you try

double.exe < input.txt > output.txt

?

[ninja01]

Wow, It worked, and thank you that, but I do not know what the heck just happen here, why I am getting 48. I did not use any ifstream to get the 24 from input.txt not ofstream to write 48 it in output.txt

?????????

[ninja01]

Thank you @seeplus, No. You need to use a 3rd party lib. I am still using the conio.h, and I guess it is considered a third party.

Also I would be happy to learn if there is another third party library that have similar functions

[Peter87]

std::cout/stdout is the standard output stream.

std::cin/stdin is the standard input stream.

The standard doesn't specify where the input comes from or what should happen to the output with those streams. That is totally "implementation defined".

[kbw]

Do you know any information about the library like where it comes from and why it is not standardized.

The history goes back to the origins of the PC and BASIC. The idea was implemented in Turbo Pascal, then Turbo C, then Turbo C++, which was then passed around and seems to continue to be used almost 30years after its release.

It's not standardized
- partly because there wasn't demand for it (PC specific)
- it doesn't neatly fit into streams (not flow operations)
- partly because it can be achieved in other ways for different input methods (interrupts for connected hardware, select() for sockets, ...)

[ninja01]

Thank you guys, I really wish to reach the level of knowledge you have.

Can some one explain, how the cmd took! a value from input.txt, send it! to double.exe, and then created! a new file double.txt and wrote! another value in it!!!!!!!!!!!!!!!!!!!!!!! and I did not even use any cmd command here. I feel tricked by my own computer)

Edit: I typed double.exe, and it was like asking me to enter an input, i enterd 52 and got 104
I think I understood the first part of the command

double.exe < input.txt > output.txt

it is like when you enter the file cmd executes it

[seeplus]

At the command line, < is input redirection. It redirects stdin to be from the specified file. > is output redirection. It redirects stdout to the specified file, overwriting what was there. >> redirects and appends.

So you write a utility program that reads from cin (stdin) and writes to cout (stdout) and the user specifies the files to be actually used.

There is also | as the pipe command where the output from one program is used as the input to the next.

If you want to redirect stderr (cerr) then you use 2> (no spaces).

See:
https://ss64.com/nt/syntax-redirection.html

[Peter87]

It's because you wrote < input.txt and > output.txt after the command.

prog < in.txt means prog should read its standard input (std::cin, std::scanf, etc.) from the file named "in.txt".

prog > out.txt means prog should write its standard output (std::cout, std::printf, etc.) to the file named "out.txt".

This is a feature of the Command Prompt/shell. The wildcard syntax * that I showed you in another thread is also such a feature. It's not something that is specified by the C++ standard and it might not necessarily work everywhere.

https://en.wikipedia.org/wiki/Shell_(computing)

[ninja01]

Ok thats why when I wrote double.exe <input.txt> I got an error. hhhhhhhhh embarrassment
I understand now, thank you a million @peter.
I am going now to try to grasp everything discuss above

[keskiverto]

There is also "pipe" (|). It redirects stdout of one program into stdin of next program.

# User must type something and will see output on terminal:
double.exe

# Shell "types" input to program from file "data.txt" and you will see output on terminal:
double.exe < data.txt

# User must type something but shell writes all output to "result.txt":
double.exe > result.txt

# Shell redirects "data.txt" to input, and output into "result.txt"
double.exe > result.txt < data.txt

# Shell "pipes" output of first double.exe into input of second double.exe:
double.exe < data.txt | double.exe
# ... and second to third ...
double.exe < data.txt | double.exe | double.exe > result.txt

# Quoting Captain: I can do this all day
echo "24" | double.exe | sed "s/4/42/" | double.exe

[seeplus]

I am still using the conio.h, and I guess it is considered a third party.

@ninja01 - what os are you using? conio.h provides console direct input/output functions (not stream buffered) without using any file streams etc. If you're using Windows then these can be provided using the Windows Console functions (and similar for Linux). Also for Linux there is https://github.com/zoelabbb/conio.h/blob/master/conio.h

For Windows, conio.h is part of the Windows SDK so is available for all Windows compilers - not just VS.

It's main usage is to test if a char is available (_kbhit() ) for reading with _getch()/_getche(). These two functions will read a char from the keyboard (without/with echo) if one is available without waiting for a \n to be entered. As has been said above, they come from the days of MS-DOS where you needed a way for getting direct keyboard char (for eg moving the cursor etc) where you couldn't have to wait for a \n to be entered. Nowadays there's very few programs written specifically for the console. Those that are are usually based upon stdin/stdout so can be used with file re-direction. Note that file re-direction does not work with the conio.h functions.

Originally there was also functions such as _cputs(), _cprintf() etc which wrote directly to the console for say the VT100 escape codes.

As Windows 10/11 console now supports VT100 codes, perhaps we should go back to those great days...