You're all talking about C++ and not LINUS TORVALDS! Have you all LOST your MINDS!? ;-)

However elsewhere there are problems. Ie, G++ and MSVC++ implement things very differently, depending on the versions and such. Ie, the contents of the v-table, location of the v-table in the object, etc. You've got both a function pointer plus a "fixup" offset to account for multiple inheritance, or thunks, whereas most OS kernels prefer to just have a simple array of function pointers which are capable of being easily used from most any language that follows the CPUs ABI (including assembler). It works on Linux because for a very long time g++ was the only offering and the newer options intentionally remain g++ compatible, whereas elsewhere this may not be true at all.

Sounds like that goes back to the "lack of standard ABI" problem. C lets you specify exactly what you want explicitly, but C++ has no consistent ABI, you get different results depending on which compiler you use.

I don't think you actually mean "virtual classes" here. But yeah, if you have to implement classes in C, maybe you should have used C++. One of C++'s problems is that it builds on C, though, so the fact that you can do some things, particularly classes, better in C++ than in C shouldn't be a surprise: that's the itch they were scratching.

The problem with C++ is that it's way too easy to write write-only code, because the language has so many features that nobody but language experts understand all of them. So we all program in different dialects, and then scratch our heads when we read other peoples' code.

But but Fedora has been using it for years without issue! Oh wait, that's because no Admin in their right mind would use Fedora as a server. But but it is stable and secure. Oh wait, your high load servers keep corrupting the journald and journalctl can't read portions of it without trying to replace the who journal with a new one. But but you can install rsyslog to fix that! Yeah, because we ALL like having to beta test an unproven product in a production environment only to be forced in resorting to something else that actually works as intended.

I'm caring less about systemd and more about how shortsighted they were when they forced everyone to use journald. The fact that I have to configure rsyslog to have a working log that does not constantly get corrupted and restart a new log, erasing the old one is annoying and shows just how unproven this entire systemd implementation truly is.

I don't think it's that bad, they don't have to convince the entire 'tech-savvy community,' they only need to convince a very small subset of that community, the people who are writing init scripts for distros. And that subset is very small.

Systemd knows that very well. They've worked very hard to make init-script writers happy, and have been very responsive in making changes. If you look through the Debian mailing lists, you can see this......there's no need to blame the NSA or others. They're just following a useful principle: find the ones who have power to do what you want, then make them as happy as possible. The systemd people have done that.

Maybe it took a week to make a small hole, that's an important detail.

We're running out of gaps.

I can't tell if you're just being obtuse, but: the developer compiles shader language to bytecode, and the graphics driver compiles bytecode to GPU native-code. Both of these stages qualify as compilation. (They're both level-reducing language-transformations.)

No. There's no way in hell that anyone's seriously suggesting running graphics code in an interpreter. Again, it will be compiled by the graphics driver. (We could call this 'JIT compilation', but this term doesn't seem to have caught on in the context of graphics.)

Why not call this what it is? It's compilation.

Objective-C actually predates C++

That and C++ was horribly immature at a time when Objective-C was not and the Next guys were developing NextStep.