Auto comment: topic has been updated by IWantImprovement (previous revision, new revision, compare).

I think the main thing is to stop treating VS Code as the tool that runs your code. It's just the editor; the compiler and terminal do the actual work. Once you're comfortable with that, you don't really need CPH or any other extension for the basic workflow.

1. Setting up raw VS Code before a contest

I would keep the setup as simple as possible. The most important thing is to have a working compiler and know how to use it before the contest starts.

First, check that g++ is available:

g++ --version

Then open your contest folder in VS Code, create a main.cpp file, and open the integrated terminal using `Ctrl + ``.

For a normal single-file problem, I would compile and run it using:

g++ -std=gnu++20 -O2 -pipe main.cpp -o main
./main

The exact standard flag should match the one you intend to use in the contest. On Windows with MinGW, the executable will generally be main.exe, which you can run with .\main.exe in PowerShell.

For testing against a file, I usually find input redirection more convenient than repeatedly typing the same test case:

./main < input.txt

You can also save the output and compare it with the expected output:

./main < input.txt > output.txt
diff -u expected.txt output.txt

The last command is available on Linux and similar environments.

If I wanted a little more convenience without installing extensions, I would create a VS Code build task in .vscode/tasks.json. Then Ctrl + Shift + B can compile the currently open source file. However, I wouldn't spend contest time building a complicated setup. A working terminal and a compiler command you can remember are enough.

Before an onsite contest, I would verify the compiler version, the C++ standard, the build command, and the way to run programs with input files. I would also practise doing everything from a clean folder, so I wouldn't have to depend on any extension or existing configuration.

2. Testing batch/grader problems

For grader-based problems, the workflow is slightly different because the submitted file often doesn't contain main().

Suppose the problem provides these files:

problem/
    grader.cpp
    solution.h
    solution.cpp
    sample.in

Here, grader.cpp usually contains the testing code and main(), solution.h declares the functions you need to implement, and solution.cpp contains your implementation.

I would first inspect the provided files and read the compilation instructions. If the package includes compile.sh, run.sh, or a Makefile, I would try to use those rather than inventing my own commands.

If the instructions say to compile the grader and solution together, the command would look something like this:

g++ -std=gnu++20 -O2 grader.cpp solution.cpp -o grader

Then run the executable:

./grader < sample.in

If there are additional implementation files, include them in the compilation command as well.

The important thing to understand is that you generally need to compile and link all the relevant .cpp files together. Compiling solution.cpp by itself may fail because it doesn't contain main(). You also normally shouldn't include solution.cpp directly inside grader.cpp; compile the source files separately and let the linker connect them.

I would keep the provided function signatures exactly as they are and pay attention to the header file. A small mismatch in a function's name, parameters, or return type can cause compilation errors even when the algorithm itself is correct.

For testing, I would run every sample provided with the problem. When the input and expected output are available as files, I would save the actual output and compare it against the expected output. This makes differences easier to spot.

One thing worth remembering is that a sample grader is not necessarily identical to the actual judge. It is useful for checking your implementation, function interface, and basic logic, but passing the samples alone doesn't guarantee correctness. When possible, I would also create additional test cases, especially small edge cases.

For problems where writing a brute-force solution is practical, I would generate random small inputs and compare the optimized solution against the brute-force answer. This can expose bugs that the official samples miss.

My overall approach would be to keep two simple workflows:

• Normal competitive programming: Compile the current source file, run it with the terminal, and redirect input from a file when convenient.
• Grader-based problems: Follow the supplied build instructions, compile the grader together with the implementation files, and test through the grader.

I wouldn't worry too much about reproducing all the convenience of CPH. The real advantage comes from being comfortable with the compiler and knowing exactly which files need to be compiled and linked. Once you understand that, switching editors becomes a pretty minor issue.