I'm practising writing recursive functions using Visual Studio 2015 on Windows 7.
I use cout to track the progress of my code, but it shows too many results and even though I stop the program I can not see the initial result... I can only see the output from the middle.
How can I see the complete program output?
The problem is that cmd.exe (the Windows commad prompt) has a fixed-size buffer for displaying output. If your program writes a lot of output, only the last N lines will be displayed, where N is the buffer size.
You can avoid this problem in several ways:
Write to a file, instead of to std::cout. All of your output will be captured in the file, which you can read in the text editor of your choice.
Redirect the standard output to a file. Run your program as my_prog.exe > output.log and the output will be redirected to output.log.
Pipe your output to the more command, to show it one screen at a time: my_prog.exe | more
Increase the cmd.exe buffer size. If you right-click on the title bar of the command window, you can select the Properties menu option. Within the Layout tab, you'll see a section called Screen buffer size. Change the Height to a larger value, and you'll be able to capture that many lines of output. Note that this is somewhat unreliable, since you often don't know in advance of executing your program how many lines it will output. One of the other approaches, using files, is often a better solution.
Note that this isn't really a problem with your C++ program. It's entirely reasonable to be able to produce a large quantity of output on the standard output stream. The best solutions are the ones that redirect or pipe the output to a file. These operations are available on most sensible platforms (and Windows, too) and do exactly what you need without having to change your program to write to a file.
I'm not sure to understand your problem, maybe you should write the output in a file instead of the standard output ? Then you will see all your results
Run your application from the commandline and redirect the output to a file:
yourapp.exe > yourapp.log
Related
When I compile and run in Clion 2018.1.3, it builds fine but nothing happens. No errors either. The console opens up, shows the path location of the project, lets me type, but it doesn't show any of my printf statements. When I run it in the debugger, everything shows up and it works fine. It wasn't like this before. I tried back tracking and no luck. Inserting a printf statement on the first line of main doesn't print on the console either.
I tried re-writing a huge chunk of the code again on a different project. No luck. Can I get some ideas on why there is this miscommunication? This is written in c++ but was translated from c using cstdio cstdlib libraries.
CLion captures the output of your program. That means output to standard output (use printf or similar) isn't line-buffered as is the default. Instead it is fully buffered. If you want output to happen you need to explicitly flush the standard output.
The reason it works with debugging might be (I'm speculating here) that CLion itself recognizes the newline and write the output then. Or that it modifies standard output to be unbuffered.
I have a C++ console application that prints some output constantly while it also accepts commands (using std::cin) from the user - output and input happen in separate threads.
If I write a text while some output appears the written text is mixed with application output. How can I prevent this behaviour?
To solve this problem, I need to display the program one line above the line where the text is typed. I'd inspire myself in Minecraft Bukkit server's solution - however I need the same for C++.
Assuming you want the output to appear while things are being typed, you'll need some screen control facilities to have the output go somewhere different than the input area. If I were tasked to implement something like this writing to a terminal I would refresh my ncurses experience. I realize you are on a Windows console and I have no idea if the Windows console is capable of the screen control needed to make it happen.
You can possibly tie custom stream buffers into std::cin and std::cout using the curses functionality under the hood but it may not be worth it. In any case, it isn't entirely trivial.
There's a windows port of ncurses called pdcurses. But if you are using visual studio there's a simple function provided called SetConsoleCursorPosition()
As you can see in u413.com: Text comes on the screen, letter by letter, which looks kind of cool,
I want to do the same thing in Console
I got the source code of version 1.2; because I dont need all the complexity of version 2;
I just need a simple Command Prompt, with text that comes on to the screen letter by letter.
I dont need most of the builtin functions offered by Console, like Transparency, Taskbar Icon, etc.
The source code base is pretty small with only about 5 files.
The main class file seems to be Console.cpp;
Since console is like a GUI application, things dont get written to the STDOUT.
but heres what happens;
A Handle is called;
And that handle apparently writes to the console;
m_hStdOut = ::GetStdHandle(STD_OUTPUT_HANDLE);
Now what I want to be able to do; Is somehow read the handle; see what text it has; And throw in a loop with a ::Sleep(20) method in it; to make sure that text appears letter by letter.
#Alf P. Steinbach I wrote the psuedo code for making the sleep command(in java) I also made use of it in every other java program I wrote, but the disadvantage was that it will work only for my programs and not every program run in the command prompt, but what I dont know is code to make a console, a windows console subsystem program, I wish it was possible with java, so that I could use it on linux too, but now, let me ask you exactly what I had in mind...
A program which simply, took input from the screen, send it to cmd.exe for processing, and sent back the reply, and all I have to do is throw in a sleep command between every character...
All I need is help, in getting this done, I wish you could start me up with this, and possible provide links and refrences to get this done...
This Console.cpp seems like a console emulator, meaning it runs OTHER programs. You don't need the source code, you can run existing console applications.
STD_INPUT_HANDLE, STD_OUTPUT_HANDLE and STD_ERROR_HANDLE are the windows handles for STDIN, STDOUT and STDERR. They basicly does the same with only a few differences in how to use it.
If you want to integrate the console into your code, then you have to understand it, and find its own output function and call that. But it won't be any standard handle or things like that.
From http://www.cplusplus.com/reference/iostream/cout/:
By default, most systems have their standard output set to the console, where text messages are shown, although this can generally be redirected.
I've never heard of a system where stdout is anything other than a console window, by default or otherwise. I can see how redirecting it might be beneficial in systems where printing is an expensive operation, but that shouldn't be an issue in modern computers, right?
Of course it could be. I may want to redirect standard out to a text file, another process, a socket, whatever.
By default it is the Console, but the are a variety of reasons to redirect it, the most useful (in step with the Unix philosophy) being the redirection of the output of one program to the input of another program. This allows one to create many small, lightweight programs that feed into one another and work as discrete parts of a larger system.
Basically, it's just a simple yet powerful mechanism for sharing data. It is more popular on *nix systems for the reason I mention above, but it applies to Windows as well.
On most systems you can redirect the standard input/output/error to other file descriptors or locations.
For example (on Unix):
./appname > output
Redirects the stdout from appname to a file named output.
./appname 2> errors > output
Redirects stdout to a file named output, and all errors from stderr to a file named errors.
On unix systems you can also have a program open a file descriptor and point it at stdin, such as this:
echo "input" > input
cat input | ./appname
This will cause the program to read from the pipe for stdin.
This is how in unix you can "pipe" various different utilities together to create one larger tool.
find . -type f | ./appname | grep -iv "search"
This will run the find command, and take its output and pipe it into ./appname, then appname's output will be sent to grep's input which then searches for the word "search", displaying just the results that match.
It allows many small utilities to have a very powerful effect.
Think of the >, <, and | like plumbing.
> is like the drain in a sink, it accepts data and stores it where you want to put it. When a shell encounters the > it will open a file.
> file
When the shell sees the above, it will open the file using a standard system call, and remember that file descriptor. In the above case since there is no input it will create an empty file and allow you to type more commands.
banner Hello
This command writes Hello in really big letters to the console, and will cause it to scroll (I am using Unix here since it is what I know best). The output is simply written to standard out. Using a "sink" (>) we can control where the output goes, so
banner Hello > bannerout
will cause all of the data from banner's standard output to be redirected to the file descriptor the shell has opened and thus be written to a file named bannerout.
Pipes work similarly to >'s in that they help control the flow of where the data goes. Pipes however can't write to files, and can only be used to help the flow of data go from one point to another.
For example, here is water flowing through several substations and waste cleaning:
pump --from lake | treatment --cleanse-water | pump | reservoir | pump > glass
The water flows from the lake, through a pipe to the water treatment plant, from the plant back into a pump that moves it to a reservoir, then it is pumped once more into the municipal water pipes and through your sink into your glass.
Notice that the pipes simply connect all of the outputs together, ultimately it ends up in your glass.
It is the same way with commands and processing them in a shell on Linux. It also follows a path to get to an end result.
Now there is one final thing that I hadn't discussed yet in my previous statements, that is the < input character. What it does is read from a file and output it to stdin on programs.
cat < bannerout
Will simply print what was stored in bannerout. This can be used if you have a file you want to process, but don't want to prepend cat <file> because of not wanting to run an extra command in the chain.
So try this:
echo "Hello" > bannerinput
banner < bannerinput
This will first put the string "Hello" in the file bannerinput, and then when your run banner it will read from the file bannerinput.
I hope this helps you understand how redirection and pipping works on Unix (some if not most will apply to Windows as well).
So far all of the answers have been in the context of the thing (shell, whatever) that invokes the program. The program itself can make stdout something other than the terminal. The C standard library provides freopen which lets the programmer redirect stdout in any compliant environment. POSIX provides a number of other mechanisms (popen, fdopen, ...) that gives the programmer even more control. I suspect Windows provides analogous mechanisms.
Any number of things can happen to the three standard file descriptors 0, 1 and 2. Anyone can launch a new process with the file descriptors attached to anything they like.
For instance, GNU screen puts the output into a pipe and allows dynamic reattaching of a session. SSH takes the output and returns it to the other end. And of course all the numerous shell redirectors regularly make use of manipulating the file descriptors.
For a program to have stdout it must be running on a hosted implementation (one with an Operating System), or on a free-standing implementation with extras.
I'm having a hard time figuring such an implementation without a console of some kind, but let's suppose for a moment that Mars Rover has a full OS and is programmed in C (or C++) and doesn't have that console
/* 2001-07-15: JPL: stdout is the headquarters */
puts("Help. I'm stuck.");
might have sent the message to NASA headquarters.
Both Windows and Linux will redirect stdout to a file if you run the program like this:
my_program > some_file
This is the most common case, but many other types of redirection are possible. On Linux, you can redirect stdout to anything that supports the "file descriptor" interface, such as a pipe, socket, file, and various other things.
One simple example of a case where one might want to redirect stdout is when passing the information to another program. The Unix/Linux command ps generates a list of processes that belong to the current user. If this list was long and you wanted to search for a particular process, you could enter
ps | grep thing
which would redirect the stdout of ps to the stdin of grep thing.
I am writing a program in C++ that launches commands from the DOS operating system using the system() command. So far so good I think. But how can I turn off the screen updating in the console window that pops up so I can't see the thousands of messages that are resulting.
Or, alternatively, how can I dump those messages in some other place....ie is there a more elegant way to deal with this rather than just turning off the screen?
thanks.
To prevent the statements themselves from being echoed, put this at the top of the script:
#echo off
To prevent output from commands, use redirection operators. To discard both the standard output and standard error streams:
nameofcommand.exe params > nul 2>&1
Note that it is always a good idea to include error handling (checking error levels, etc.) in your scripts, especially if you discard all output as shown above.
In the batch file you can redirect the output to a file. E.g. echo this goes to a file > log.txt would write the contents of the echo statement to the file.
See this article on command redirectors.
You should use the _popen function, which will write the output to a stream instead of the console.
It's quick and dirty I know, but...alternatively, set the foreground colour of the window to the same colour as of the background in order to hide the texts flashing by, see here for an example of how to do this, its in the 7th posting on that page that shows the code to do so. The color you would want is 0x0, black on black...in that way, it looks blank, and no one would see it..
Dirty I know...admittedly SLaks answer above would be more elegant...
Hope this helps,
Best regards,
Tom.