FAQs about Comparing FIles and I/O Redirection

How can I compare my output to the sample output?

First, get a copy of your program's output using the same inputs as we used to create the sample output. The best way to do this is I/O redirection, which also can be used to automate the process.

Second, see if your output file matches our output file.

How do I tell if my output file matches the sample output file?

1. Use an old data-cruncher's trick: Print out the two files with identical fonts, margins, etc. Lay the two pieces of paper on top of each other, hold them up towards a strong light, and look through them. Line them up, and any differences will usually be obvious.

2. Unix has a "diff" command that compares two files. With a little experience, you can use it to pinpoint where two files are different. For example, type in

diff my_output.txt sample_output.txt

and diff will tell you whether the files are identical, or print out a list of the different lines along with some gobbledegook that a reference will tell you how to interpret.

3. There is also a Unix "sdiff" command that you invoke like diff, but it shows the two files side-by-side with any different lines marked. This is much easier to use than diff.

4. Many IDEs come with either a built-in or separate application for comparing two files by displaying them side-by-side like sdff.

5. Some text editors have a similar comparison feature - check your favorite.

What is I/O redirection?

Input/output (I/O) redirection means connecting input and output streams to a different device than they are normally connected to. In particular, you can redirect the standard input stream (cin or stdin) from the keyboard to an input file, and the standard output stream (cout or stdout) from the display to an output file. Thus you can have your program taking input from a file instead of the keyboard, and sending it to a file instead of the screen, without having to change the I/O statements in your program. Rather, cin and cout are connected to files instead of the keyboard and screen.

What are the disadvantages of redirecting I/O?

One drawback is that the keyboard input is not written to the output file, so your program has to "echo" the input in some way in order for there to be a record of it in the output file. In other words, the output file will not include the input from the keyboard (or the input file). This is OK, once you get used to it.

Another drawback is if output is redirected, you don't get to see it on the screen, making it hard to tell what your program is doing. Thus you only want to use I/O redirection for a final "production run" or a testing run - you can't usefully interact with the program if I/O is redirected.

Finally, once I/O is redirected to a file, the keyboard and/or the display will no longer be connected to the program. You will have to let the program finish running and start it again before you can do normal keyboard/screen I/O with it again.

How do I redirect I/O?

You can do this in *any* standard C/C++ programming environment using our handy "redirect_io" function - this prompts for filenames and uses an obscure function, freopen, in the stdio library, to do the redirection from your program. It's pretty simple and should work for any C/C++ implementation.

To get the header file and implementation file for a multiple-file project, download the files from the examples/redirect_io directory and follow the instructions in the comments.

You can also download these files with ftp from the course directory; look for the subdirectory named "examples/redirec_io".

How can I redirect I/O without changing my code?

If you don't want to use our redirect_io function, then you can use command-line redirection in a Unix shell or Windows DOS prompt window:

Say your executable is p.exe, and the input is in a file, e.g. inp.txt. Then, on the command line, type:

p.exe < inp.txt > out.txt

Your output will be left in out.txt.

Mac users: Use the Terminal program to get a Unix shell, and cd to the directory containing the executable (e.g. build/release in the Xcode project directory); either put the test files in the same directory, or put complete paths for them in the command line.