There are very few more heated arguments in this world that two C++ developers arguing about the correct way to do things.
This toot brought to you by the two day long argument I'm reading about `std::to_underlying` for C++ enum classes.

Also C++ devs who took Abrash's "measure to know the performance of something" waaaay to seriously.

Like, I can know certain practices hinder performance of things without measuring.

This is why SIMD APIs exist. Compilers are pretty magical, but they're not *that* magical.

This is something I find really really interesting about a lot of C++ devs. The language is supposed to be all about performance, but a lot of the arguments are about best practice within the language, proper architecture, avoiding footguns, and so often arguments specificly about high performance architectures are scoffed at in favor of "proper OOP" or assuming that you can't know something is high performance without measuring.

It's baffling.

@fuzzybinary I think the trick is that it’s different things to different people. I’ve worked with embedded engineers who were afraid of C++ because it was too high level, game devs who’ve loved it but had strict rules against OOP/inheritance/the virtual keyword, and app devs who considered it some sort of ancient artifact beyond comprehension “don’t touch the .so, it’s what makes our app fast!” but otherwise needed the oop abstractions. And all of them will duke it out on forums 😆
@pux0r3 Yeah. Actually, something I read in Effective C++ which I'd NEVER thought about (and that book is how old!?) that C++ is actually 3 languages, and it's practicies are different based on which version of the language you're using.
@fuzzybinary @pux0r3 I can definitely see that, the C++ I write (and I've seen a lot of other embedded and game devs write) I've seen kinda "jokingly" referred to as "C+", no exceptions, no rtti, single inheritance only as makes sense, generally little/no stdlib use. I think that's what makes it so versatile though, c++ has TONS of features, but in practice you just use whatever small subset and design patterns make sense for your own use case.

@raptor85 @fuzzybinary Ha, -noexcept and -nortti are even better examples of what I was thinking of too. I’ve worked in code bases that worked better on both sides of those flags 😆

I tend to play with different languages for fun, and I always end up back at C++ because it’s not _that_ broken and I can usually slurp in whatever I thought was cool from my latest round of new language spelunking. Just don’t tell the Rust devs that I’m not (yet) totally sold on the borrow checker.

@pux0r3 @raptor85 randomly relevant article Google surface to me not 10 seconds ago https://16bpp.net/blog/post/noexcept-can-sometimes-help-or-hurt-performance/
16BPP.net: Blog / `noexcept` Can (Sometimes) Help (or Hurt) Performance

@fuzzybinary @raptor85 the initial argument against exceptions at my first job was a vague "it's slower usually" mixed with "look at all this extra assembly this generates, do you want to read this?"

Now, even if it were slower (which I love this article for 😆), I've been radicalized into thinking it can be clearer to read and manage than piles of "if error" checks or the infamous `goto error` - and therefore faster in the "I can better reason about my code structure" way.