Hello!
I am pleased to report that two rounds of Codeforces have gone quite well in terms of the work of Codeforces, I am very glad about it. These days nights I spent in a profiler, fixing the code, researching the settings of MariaDB.
In addition, I managed to allocate several hours on Sunday (to be honest, until Monday morning) to finish the long-planned innovation.
Meet, diagnostics of solutions in C++!
Many Codeforces visitors are already tired of the questions of less experienced participants: "Why does my solution not work on some test on the Codeforces servers, if I locally launch it and it works correctly? You have the wrong compiler/servers!" In 99% of cases this is an example of undefined behavior in a program. In other words, the program contains mistakes that, due to a number of circumstances, are not reproduced at local launch, but are reproduced at launch on the Codeforces servers.
Sometimes, it's not easy to notice such a mistake. A small overflow of the array can lead to an incorrect answer on the test and to an runtime error of the program.
In g++/clang++ there is a remarkable tools called sanitizers. It's such a way to compile a program in a special mode so that when it's working, it will check it for undefined behavior (and some other errors) and, if any, print them to stderr. The drmemory (it is similar to valgrind, but for Windows) has similar functionality, which starts the program in a special mode to detect errors. With such two diagnostic launches, the performance of the program suffers tremendously (the program is executed 5-100 times slower and requires more memory), but often it's worth it.
Now automatic diagnostics in some cases will prevent a question like "Why does not work ???", indicating the error or its appearance!
If your solution:
- written in C++,
- finishes with a verdict "wrong answer" or "runtime error"
- on this test worked extremely quickly and consumed a little memory,
then it will be restarted using special diagnostic compilers (clang ++ with sanitizers and g++ with drmemory). If an execution error occurs during this launch, the diagnostics log will be displayed in the test details in the "diagnostics" section. Of course, this entry will contain a technical report in English, but often it will indicate to you the error of the program. Often it contains the cause of the mistake and even the source code line. If the diagnostics are not displayed, then at least one condition above is not fulfilled or the diagnostics has not detected any errors.
Example of the diagnostics: here it is written that there was an array out of range error in the line 78.
Thus, the diagnostics will sometimes help you to find a mistake like "out of bounds error", "signed numbers overflow", "uninitialized variable", etc. Carefully read the diagnosis and do not make such mistakes in the future!
I wish your programs did not fail. I hope the innovation will be useful!
There are big plans as it is useful to apply such diagnostics. Do not go far, wait for news, soon there will be more innovations!
P.S. Also, diagnostic compilers are simply available for use. For example, you can use them on the "Custom invocation" tab. I recall that the program runs many times slower and consumes more memory in diagnostic mode.