JATtho

o ou mean smirk?

C++: you sure you want to do this? This will either: a) blow your foot off b) be too fast to be measured in micro-benchmarks.

b. B. B. a. then B.

You have chosen to simultaneously blow your arm off and be the fastest code thing on the planet. Congrats. Yes.

I was suspicious as heck of this link, but I thank you for being benign.

My most common typo is gti <random command> and I'm considering to alias it as rm -rf --no-preserve-root /

name your function as malloc() and see to world burn and generate bugs at factorial rate.

Lettme introduce you to ackermann's function:

int ack(int m, int n) {
    if (m == 0) {
        return n+1;
    } else if((m > 0) && (n == 0)){
        return ack(m-1, 1);
    } else if((m > 0) && (n > 0)) {
        return ack(m-1, ack(m, n-1));
    }
}

You won't run out of stackoverflows any time soon.

A lot. That's the answer.

std::chrono::neutronstar_clock

After 362879 wrong answers you will pass. Or after 2,0922789888×10¹³ tries if it's a fancy 4x4 grid.

To produce 1 commit, I end up rebasing the damm thing at least 3 times. If there is an problem, it's at least 2³ times.

volatile int blackhole;
blackhole = 1;
const int X = blackhole;
const int Y = blackhole;

Compiler is forbidden to assume that X == 1 would be true. It's also forbidden to assume that X == Y. const just means the address and/or the data at the address is read only. const volatile int* const hwreg; -> "read only volatile value at read only address hwreg". Compiler can assume the hwreg address won't magically change, but can't assume the value read from that address won't.

Please, no, I get flashbacks from my 6-month journey (still ongoing...) of the code review process I caused/did. Keeping PR scope contained and small is hard.

From this experience, I wish GitLab had a "Draft of Draft" to tell the reviewer what the quality of the pushed code is at: "NAK", "It maybe compiles", "The logic is broken" and "Missing 50% of the code", "This should be split into N PRs". This would allow openly co-develop, discuss, and steer the design, before moving to nitpicking on the naming, formatting, and/or documentation details of the code, which is likely to drastically change. Drafts do work for this, but the discussions can get uncomfortably long and convolute the actual finishing of the review process.

Once both reviewer(s) and the author agree on the code design, the "DraftDraft" could be collapsed into a link in an normal Draft to be mocked next. The scope of such draft would be limited by the earlier "DraftDraft".