Although not feasible if you have to write all code from scratch, [this template](https://github.com/bqi343/USACO/blob/master/Implementations/content/contest/CppIO.h) is very helpful for simplifying input / output / debug output. Note that `dbg()` only produces debug output when `-DLOCAL` is included as part of the compilation command, so you don't need to comment out those lines before submitting.
According to [this comment](https://codeforces.com/blog/entry/60999?#comment-449312), `-Wl,-stack_size -Wl,0xF0000000` increases the stack size on Mac. Without it, you might get a runtime error if you have many levels of recursion. This matters particularly for contests such as Facebook Hacker Cup where you submit the output of a program you run locally.
/usr/local/Cellar/gcc/9.2.0_1/include/c++/9.2.0/bits/stl_vector.h:1043:34: runtime error: pointer index expression with base 0x000000000000 overflowed to 0xfffffffffffffffc
I don't use these because they can significantly slow down compilation time and I don't find these messages particularly helpful (but maybe I'm wrong?)
## Running (on Mac)
According to [StackOverflow](https://stackoverflow.com/a/60516966/5834770) the `& fg` is necessary for getting `zsh` on Mac to display crash messages (such as segmentation fault). For example, consider the running the first `prog.cpp` above with `run prog`.
If `& fg` is removed from the run command above then the terminal displays no message at all. Leaving it in produces the following (ignore the first two lines):
For example, suppose that `prog.cpp` consists of the following:
```cpp
#include <bits/stdc++.h>
using namespace std;
const int BIG = 1e7;
int a[BIG];
int main() {
int sum = 0;
for (int i = 0; i < BIG; ++i) sum += a[i];
cout << sum;
}
```
Then `co prog && gtime -v ./prog` gives the following:
```
Command being timed: "./prog"
User time (seconds): 0.01
System time (seconds): 0.01
Percent of CPU this job got: 11%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.22
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 40216
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 91
Minor (reclaiming a frame) page faults: 10088
Voluntary context switches: 3
Involuntary context switches: 38
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
```
Note that $10^7$ integers require $4\cdot 10^7\cdot 10^{-3}\approx 40000$ kilobytes of memory, which is close to $40216$ in the above output as expected.
## Stress Testing
You can use a [simple script](https://github.com/bqi343/USACO/blob/master/Implementations/content/contest/stress.sh) to test two solutions against each other. See Errichto's video for details.
To do this, set a "breakpoint" at a certain line of code. When the code runs to that breakpoint, it will pause and you will be able to inspect all the different variables at that certain instance.
There are two more useful and common operations. Once you are at the breakpoint, you may want to see what happens after the current line is executed. This would be the "Step Over" button that will allow you to move to the next line. Say you are at a line with the following code: `dfs(0,-1)`, if you click "step over" the debugger will ignore showing you what happens in this function and go to the next line. If you click "step in," however, you will enter the function and be able to step through that function.
In essense, a debugger is a tool to "trace code" for you. It is not much different from just printing the values out at various points in your program.
- You cannot see the overall "output" of your program at each stage. For example, if I wanted to see every single value of `i` in the program, I could not using a debugger.
- Most advanced competitive programmers do not use debuggers; it is quite time inefficient.