but enough for that answer to be valid

Highly arguable. Especially without specifications on the lamp. It could be a rather dim and small one. Then, you either need special equipment or supersenses.

Here you can test how identifiable you are:

https://coveryourtracks.eff.org/

https://amiunique.org/

gnew?

The more experience I gain over the years, the more this feels relatable. I had to pull myself together to keep my comments regarding kaputt Nvidia APIs civil in my code and commit messages.

Ah Nvidia. Always a fucking PITA (not the bread kind). I wonder how they have managed to become the most valuable chip manufacturer worldwide.

Good question! I have read a bit more about it and this does indeed heavily depend on the respective compiler implementation. Depending on the compiler, it may prefer default if-else ladders for few cases. For more, dense cases, LUTs may play a larger role. For less dense cases binary search might be chosen.

I inspected the generated assembler code of your (slightly extended) example via https://godbolt.org/

The code I used:

void check_uv();
void check_holograph();
void check_stripe();
void check_watermark();

void switch_test(int banknoteValue) {

    switch (banknoteValue) {
        case 5000:
            check_uv();
            check_holograph();
        case 2000:
            check_stripe();
        case 1000:
            check_watermark();
    }

}

Using x86-64 gcc 15.2 this leads to a couple of cmp followed by je instructions, so “compare” and “jump to label if equal” which basically is a typical if-else ladder. I get the same for x64 msvc v19.43.
Changing the cases to 1, 2 and 3 instead of 5000, 2000 and 1000 does not change the outcome.

Increasing to 23 different but incrementally increasing cases (cases 1 to 23) does not change the outcome as well for gcc. But here msvc has introduced a performance optimization: it decreased the input value by one to get a range of 0 to 22 and then created a jump table, so a LUT with execution addresses. (I am not going to detail the assembler commands logic here, but you can use the C++ code below and take a look yourself. :) )

So even in this simple example we can already see how different compilers may implement switch cases differently depending on its structure. Even though gcc chose the apparently less efficient solution here, usually one may trust on the compiler choosing the most efficient switch implementation. ;)

As far as I know, we would not even get the chance of similar optimizations if choosing if-else ladders directly instead of a switch-case structure. It would be interesting to put this to a test though and see whether some compilers translate if-else ladders equivalently with the performance benefits that can currently come with switch structures.

The inflated code:

void check_uv();
void check_holograph();
void check_stripe();
void check_watermark();

void switch_test(int banknoteValue) {

    switch (banknoteValue) {
        case 1:
            check_uv();
            check_holograph();
        case 2:
            check_stripe();
        case 3:
            check_watermark();
        case 4:
            check_watermark();
        case 5:
            check_watermark();
        case 6:
            check_watermark();
        case 7:
            check_watermark();
        case 8:
            check_watermark();
        case 9:
            check_watermark();
        case 10:
            check_watermark();
        case 11:
            check_watermark();
        case 12:
            check_watermark();
        case 13:
            check_watermark();
        case 14:
            check_watermark();
        case 15:
            check_watermark();
        case 16:
            check_watermark();
        case 17:
            check_watermark();
        case 18:
            check_watermark();
        case 19:
            check_watermark();
        case 20:
            check_watermark();
        case 21:
            check_watermark();
        case 22:
            check_watermark();
        case 23:
            check_watermark();
    }

}

That falls into the “very desparate” part. As long as there are companies that have better recruitement processes it will help if most people prefer those over others. If all of these companies reject an applicant then this applicant might become “desparate” and turn towards worse companies. So it’s more the mass of people that influence the market and can therefore improve its conditions.

/j: joke
/s: sarcasm
/i: irony

Easy:
You take GPU. And then you put GPU.
Understood? /j

switch case structures are very efficient in c and c++. They work similarly like an offset into memory. Compute the offset once (any expression in the ‘case’ lines), then jump. Using primitives directly, like here with chars, is directly the offset. Contrary to if-else branches, where each case must be evaluated first and the CPU has basically no-op cycles in the pipeline until the result of the branch is known. If it fails, it proceeds with the next one, waits again etc… (Some CPU architectures might have stuff like speculative branch execution, which can speed this up.)

However, code-style wise this is really not elegant and something like your proposal or similar would be much better.

At first I thought, "How are they going to compress 256 values, i.e. 1 Byte sized data, by “rearranging into integers”?

Then I saw your code and realized you are discarding 228 of them, effectively reducing the available symbol set by about 89%.

Speaking of efficiency: Since chars are essentially unsigned integers of size 1 byte and ‘a’ to ‘z’ are values 97 to 122 (decimal, both including) you can greatly simplify your turn_char_to_int method by just substracting 87 from each symbol to get them into your desired value range instead of using this cumbersome switch-case structure. Space (32) and dot (46) would still need special handling though to fit your desired range.

Bit-encoding your chosen 28 values directly would require 5 bit.

I ended up not getting it because the whiteboard guy didn’t like that I didn’t remember the formula for an n-dimensional plane off the top of my head.

What do they want? A walking wikipedia or someone who knows how to look up necessary stuff, evaluate it and put it appropriately into practise?

Don’t participate in such a process and the problem solves itself (unless you are very desperate). As long as companies find some idiot who jumps through these hoops, they will continue to do this. When they realize that they are deterring candidates with this shitty process, they might start changing it.

There is Windows IoT.

Haha, meaningful, informative comments that make it easier to understand the code of course. ;)

But I must o p t i m i z e! ó_ò

Yes, let’s spend two hours on figuring out optimal values of preallocating a vector for your specific use-case. It’s worth the couple of microseconds saved! Kleinvieh macht auch Mist.

That what comments and documentation are for.

I suppose it’s a matter of experience and practise. The more you wotk with it the better you get. As usual with all things one can learn.

I mostly see warnings when compiling source code of other projects. If you get a warning as a dev, it’s your responsibility to deal with it. But also your risk, if you don’t. I made it a habit to fix every warning in my own projects. For prototyping I might ignore them temporarily. Some types of warnings are unavoidable sometimes.

If you want to make yourself not ignore warnings, you can compile with -Werror if using GCC/G++ to make the compiler a pedantic asshole that doesn’t compile until you fix every fucking warning. Not advisable for drafting code, but definitely if you want to ship it.

Febrempril, sounds like a Tolkien character.

For dipping your toes into a new topic I think it’s perfectly fine. It helps to provide useful pointers for further “research” (in a sense that would meet your requirement) and also manages to provide mostly accurate overviews. But sure, to really dive into this, LLMs like ChatGPT and co. are just some low-level assistants at best and one should go through the material themselves.