Editing PEG:C++ Lesson 6 for Pascal Users

{{C++ Lesson for Pascal Users|6}}
C++ programmers find themselves in the wonderful position of having three parallel sets of I/O functions available to them.<br><br>
The first level is the operating-system level. In Linux, there are functions, mostly located in <code>unistd.h</code>, that make direct requests to the kernel of the operating system to perform the desired I/O operations. There is little point to using these, however, because they are inconvenient (''e.g.'', you cannot read and write integers, only bytes) and depend on a particular operating system. (They do not, for example, work on Windows; Windows has its own set of such functions, which in turn do not work on the judge.) They include <code>open()</code>, <code>read()</code>, and <code>write()</code>. We will not discuss them any further here, and I strongly discourage their use in algorithm problems, unless you are masochistic enough to submit assembly language solutions, in which case you have no choice.<br><br>
As you probably know, almost everything that can be done in C can be done in C++. The developers of the C standard library designed its I/O functions to be much less painful for the programmer as well as portable from machine to machine. This is why you can code on a Windows machine and submit to a Linux judge and get the same results. From them we have a second set of I/O functions that includes <code>fopen()</code>, <code>scanf()</code>, <code>printf()</code>, <code>gets()</code>, <code>puts()</code>, <code>getchar()</code>, <code>putchar()</code>, <code>fread()</code>, and <code>fwrite()</code>, defined in the header <code>stdio.h</code>.<br><br>
Of these, you should pay close attention to <code>scanf()</code> and <code>printf()</code>. They will do almost everything that <code>cin >></code> and <code>cout << do</code>, respectively, but often more quickly and elegantly. They work by parsing a ''format string'' to determine the expected format.<br><br>
For example, the statement <code>printf("%d",x);</code> assumes that <code>x</code> is an integer variable, and prints its value. The code <code>%d</code> stands for <code>int</code>. You are not limited to printing one item at a time; <code>printf("Here are two integers: %d and %d\n",x,y);</code>, when executed with the values <code>x=3</code> and <code>y=5</code>, will print <code>"Here are two integers: 3 and 5"</code>, followed by a newline (that's what <code>'\n'</code> stands for). The same effect can be achieved by the code <code>cout << "Here are two integers: " << x << " and " << y << endl;</code>, but the <code>printf()</code> code is far more elegant and less cluttered. In a similar vein, <code>%f</code> prints a <code>float</code> or <code>double</code>, and <code>%c</code> prints a <code>char</code>. You can have as many of these <code>%</code>-expressions (''format specifiers'') in a format string as you wish. What is very useful about <code>printf()</code> is that it makes it easy to print fractional numbers to the specified number of decimal places: the command <code>printf("%.2f",3.14159);</code>, for example, prints <code>"3.14"</code>. Remember that the order of parameters after the format string must match the order of format specifiers, from left to right, in the format string, if <code>printf()</code> is to work as intended. (To print a literal percent sign, use <code>%%</code>.)<br><br>
<code>scanf()</code> is very similar. It attempts to ''match'' the format string with the actual data available from input. When it encounters a format specifier, it attempts to read the type of value specified and store it into the corresponding variable. There is a bit of a snag here. In Pascal, you were able to pass parameters either by value or by reference, but the distinction was transparent: all that changed was adding the keyword '''var'''. C did not work this way; to pass by reference, you had to pass the address of the variable as a pointer by prefixing it with an ampersand, <code>&</code>. For example, the command <code>scanf("Here are two numbers: %d and %f",&x,&y);</code> will attempt to read the string <code>"Here are two numbers: "</code>, followed by an <code>int</code> (storing it into <code>x</code>), the string <code>" and "</code>, and a <code>float</code> (storing it into <code>y</code>). If a matching error occurs (''e.g.'', if we reach the end of file and there is no more data, or if the input does not contain the strings we expected, or if strange characters are present), <code>scanf()</code> returns <code>-1</code>. (Note that whereas %f prints both <code>float</code>s and <code>double</code>s, <code>scanf()</code> distinguishes between them; <code>%f</code> reads <code>float</code>s whereas <code>%lf</code> reads <code>double</code>s.)<br><br>
More information, including additional format specifiers (yes, there is one for every basic type in C --- but note that <code>bool</code> did not exist in C and was introduced in C++) and cool features can be found on the appropriate pages of [http://www.cplusplus.com http://www.cplusplus.com].<br><br>
The third set of I/O functions is the set that involves <code>cin</code> and <code>cout</code>, defined in the <code>iostream</code> header. (<code>iostream</code> includes <code>stdio.h</code> automatically.) These were introduced with C++. The insertion and extraction operators usually suffice, but there are additional functions such as <code>getline()</code>, <code>cin.getline()</code>, and <code>cin.ignore()</code> that you may want to read up on. Controlling the format of output cannot be done as elegantly as it can with <code>printf();</code> instead, the header <code>iomanip</code> provides a solution to this task. I will assume that you are all competent users of search engines and leave it to you to learn how to use <code>iomanip</code>, should the need arise.<br><br>
I took the time to explain <code>scanf()</code> and <code>printf()</code> not because of their elegance, though. Rather, it is because in g++ versions before 4.1 (''I think''), <code>cin >></code> was very slow, and <code>cout <<</code> somewhat slow. So slow, in fact, that it is actually possible, on some problems, to TLE just from reading input. (An example is [http://pegjudge.ath.cx:5050/problem/ccc09s4 Ship & Shop].) When working a problem from somewhere other than the PEG Judge that has large cases (''i.e.'', more than 50 kB input or 500 kB output), I strongly recommend that you play it safe by using <code>scanf()</code> and <code>printf()</code> instead of <code>cin >></code> and <code>cout <<</code>.<br><br>
What about on the Judge? In recent g++ versions, including the 4.1 used by the Judge and beyond, the design flaws of <code>cin >></code> and <code>cout <<</code> have been largely fixed. (I do not know if they persist in Visual C++, but then again online judges don't use that anyway.) However, they are still slow because they have to constantly ''synchronize'' with the I/O functions provided by C. You can circumvent this by promising the program that you won't use any C input functions, and using the statement <code>cin.sync_with_stdio(false);</code>; similarly, if you won't use any C output functions, you can use <code>cout.sync_with_stdio(false);</code>. These increase the speed of <code>cin >></code> and <code>cout << </code> (respectively) dramatically on the recent g++ versions, so that they should be fast enough to solve any problem; in fact, they are often faster than <code>scanf()</code> and <code>printf()</code>. (If you break your promise, though, you will get some nasty error like SIGSEGV, or your program just won't work properly and you'll get WA.)<br><br>
Notice that the <code>sync_with_stdio(false)</code> trick doesn't work particularly well on judges with older g++ versions, so, as I said, only use it on the PEG Judge, unless you are absolutely sure that the judge to which you submit your code has one of the newer g++ versions. On older versions, <code>scanf()</code> and <code>printf()</code> are often your only reasonable choices.