<resource source="Errichto" title="Video - How to test your solution" url="https://www.youtube.com/watch?v=JXTVOyQpSGM" starred>using a script to stress test</resource>
<resource source="Errichto" title="Asking for help FAQ" url="https://codeforces.com/blog/entry/64993" starred>some parts from above video</resource>
</resources>
## Within Your Program
### Style
<resources>
<resource source="CF" title="Competitive C++ Manifesto: A Style Guide" url="blog/entry/64218" starred> don't agree with everything but important to read nonetheless</resource>
</resources>
### Assertions & Warnings
<resources>
<resource title="Asserts" source="LearnCpp" url="https://www.learncpp.com/cpp-tutorial/7-12a-assert-and-static_assert/" starred>includes static_assert and #define NDEBUG</resource>
<resource title="Assertions" source="GFG" url="assertions-cc">subset of above</resource>
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):
- [time -v on Mac](https://stackoverflow.com/questions/32515381/mac-os-x-usr-bin-time-verbose-flag)
- use `gtime`
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.
## Debuggers
(gdb, valgrind?)
Using a debugger varies from language to language and even IDE to different IDE. For now I will describe the basic operations of a debugger.
A debugger allows you to pause a code in its execution and see the values as a given point in the debugger.
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.
Pros of using a debugger:
- No need to write print statements so you save time
- You can step through the code in real time
Cons of using a debugger:
- 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.