> exceptions are slow<p>There are proposals to introduce better exceptions into C++. Like this: <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf" rel="nofollow">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p07...</a>.<p>But until it's not in the standard, people should use std::expceted instead.
> Virtual vs static polymorphism<p>> std::visit over std::variant<A, B, C> is lowered to a switch over the active alternative.<p>> In this case, layout is probably doing more work than the dispatch mechanism itself.<p>Very likely because last time I checked visit lowers to a virtual call.
I’ve seen some terrible horrid nonsense from them and even the best compilers don’t use a third of the opcodes our modern CPUs boast of. Nobody understands the big compilers any more either, they’re all too huge. And soon AI will be “improving” hem too.<p>You want to see a beautiful compiler? Look at Plan 9’s compiler suite. A man could understand and even build on that.
Trust the compiler - sure - but we can't change the whole program by using -ffast-math, unfortunately, so that particular one is out.
I really dislike the complexity of modern C++ language specs, but does it obscure much detail about FP ops?<p>TL;DR:<p>A vast majority of the programmers I've worked with don't understand the nuances of FP <i>in general</i>, nor the various extents of IEEE-754 support in different programming languages.<p>So for <i>important</i> numerical programming, I think clarity regarding the FP operations being performed can be crucial. I'm just unclear if modern C++ is a significant factor for that.
Are you a fool?<p>Another name for compilers: invisible backdoor injectors. The more complex is the syntax the more it is likely to happen... I let you guess how the "sane" syntax from c++ and similar (LOL) does fit here...