for (int i = 0; i < n; ++i) {
for (int j = 0; i < n; ++j) {
...
instead of what was intended (j < n).So if you have (in your pre-written library of snippets) a macro like
#define FOR(i, n) for(int i = 0, _n = n; i < _n; ++i)
then you can write: FOR(i,n) FOR(j,n) {
...
(the _n in the macro is for cases like FOR(i, v.size()) to avoid recomputation) and at least avoid that particular error. Of course other sorts of silly errors are still possible; some examples here: https://www.quora.com/What-is-the-worst-mistake-youve-made-i...https://github.com/LoupVaillant/Monocypher/commit/d7bb73f65a...
So I have this function, `crypto_wipe()` that wipes memory regions with `volatile` so the compiler doesn't optimises it away. In the link above I was using it thus:
crypto_stuff(stuff_ctx *ctx) {
// stuff
crypto_wipe(ctx, sizeof(ctx)); // BUUUG!!
}
See the bug? I should have dereferenced `ctx` in the sizeof operator. As it was, was only wiping a pointer's worth of data instead of the whole structure. Oops.Now I write this instead:
crypto_stuff(stuff_ctx *ctx) {
// stuff
WIPE_CTX(ctx); // correct!
}
The amount of repetition I avoid this way is almost negligible, but that was enough to trigger a mistake (I had quite a lot of wiping to do). With the macro, errors are much easier to spot (so much so that I am willing to give 100€ to anyone who finds such an error, see https://monocypher.org/quality-assurance/bug-bounty)That being said, I've found that competitive programmers sometimes write extremely ugly code. It's surprising to see how they are able to solve such complex problems, and yet can't (or don't value) write readable and structured code. Maybe they are so sharp that they don't feel the need to make their code more readable.
And I don't mean to say the whole thing is bunk. I found some really good info farther into the book, especially about algorithms, which I think will help towards interviewing candidates.
Speed is the goal here.
Then why is it used in the interview process for the latter?