I loved it when I was younger, but I had trouble recommending it more recently because its tone is adjacent to personally attacking people who like Java.
As I get older, I do tend to be more conciliatory, but I do think that even the people who like Java are perpetuating pain and struggle for others that will have to learn some lessons the hard way.
Agree, but it helps to remember that it’s a product of its time. Feels like we’re overdue for a similar piece poking fun at Node/JavaScript and all of its foibles.
> you can't trust that your enums have a value inside their interval
If you don't set the underlying type, assigning a value that doesn't match an enumerator via `static_cast` is undefined behavior. See https://en.cppreference.com/w/cpp/language/enum . (Doing weird pointer casting things is also undefined behavior per the strict aliasing rule, though, come to think of it, I'm not sure whether memcpying an out-of-range value into an enum through the "reinterpret_cast to `char*`" loophole is undefined behavior.)
> If the underlying type is not fixed and the source value is out of range, the behavior is undefined.
Note the fine print about the meaning of ”out of range”:
> (The source value, as converted to the enumeration's underlying type if floating-point, is in range if it would fit in the smallest bit field large enough to hold all enumerators of the target enumeration.)
So this is not undefined:
enum E { A = 0, B = 1, C = 2 };
E valid = static_cast<E>(3);
Even if that covered all the problem space (instead of replacing it with a much larger one), if your code is flawless, parsing and validating are equivalent.
Choosing one just makes a difference because code has problems.
The article links out to Compiler Explorer (https://godbolt.org/), which shows the exact compiler version and options and lets you play with different ones. It shouldn’t matter which compiler — the standard prohibits optimizing this.
I suspect that it's because perilogue code, of functions or of inner block scopes, simply isn't subjected to optimization, other than the settings that control the existence of framepointers, smart callbacks, and whatnot, which are fairly fixed alterations to the boilerplate. People also probably don't want to risk peephole optimizing code that has been carefully arranged to exactly match calling conventions, possibly including expectations of specific instructions in specific places.
Ironically, the best optimization that isn't done to perilogues in the x86 architecture is to take out the PUSH/POP instructions and replace them with MOVs and LEAs, ironically making them more like perilogues on other ISAs.
I had hoped that this article wouldn’t require x86 assembly fluency to read; it really is a “port” of my prior article on x86-64 assembly. I wrote it because mobile developers, at least, probably care more about ARM64 than x86-64. Is there anything I can do to make this article similarly approachable to the x86-64 one?
Explaining things in terms of how they are unlike x86 is what makes people think that they need x86 knowledge as a pre-requisite.
The mechanics of branch-with-link can be explained without using x86 as a base. It's a call where the return address is saved in a register and code controls where and when that address is spilled to the stack, rather than it always being on the stack. This is common to several ISAs.
The explanation that sp is a "stack pointer" is like pretty much every stack-based ISA, and does not need special reference to the x86. The idea that all instructions are the same width, similarly, is common to several ISAs, and does not need special reference to only one of the architectures where it is not the case.
And operand order is not unlike x86, but rather unlike a specific assembly language for x86, for which there are alternatives.
It's approachable either way. The main reason I mentioned x86 familiarity is because you make references to your previous post as well. I'm already reasonably fluent in both x86 and arm assembly, so I may not be the best judge though
TIL! I went and dug up a citation: https://blog.reverberate.org/2013/08/parsing-c-is-literally-...