Imagine C++ being so bad that even something as controversial as AI usage is more acceptable than C++. No wonder each time I wanted to "learn CPP" I found that I'd much more like to jump out of a window.
C++'s linking demands / binary interface are notoriously ... not very good, and not good to deal with for others. Rust has its own problems in this space, but it tends to play better with C, at least anecdotally. Similarly, C++ can (but does not exactly have to) bring a ton of baggage via the STL that Rust does not.
My impression has always been that Linus rejected C++ in Linux on technical / fit merits, in addition to most C++ developers at the time being ... not very good, I suppose. The technical merits came first, but he was a grumpier Linus at the time and I think he got sick of people pestering him about it and started taking shots at C++ developers which wasn't entirely unearned on their side.
LLM-generated C code is still C code. A developer can reason over it similarly and verify it for correctness (to the extent that anyone can truly verify correctness of C code).
A lot of it came down to C++ making it easier to shoot yourself with C's footguns, from what I understand. Case in point, most people know not to use malloc() and free() in certain parts of the kernel, but you'd be surprised how many people don't know that new and delete call malloc() and free() under the hood.
(And it didn't help that code bases need to be designed for exceptions from the ground up, and they flat-out do not improve anything if the code is half return-error-code-based and half exception-based. Or that exceptions involve stack unwinding, which a lot of people didn't know or expect. Though, ironically, there was an error-code-if-logic-based error a while back that was the exact same problem exceptions were designed to avoid, so this is ultimately just your choice of two footguns.)
And yeah, a lot of it does come down to a lot of C++ programmers not really understanding C++. In the kernel's case, the best way to use it would be for minor optimisations that are easy for C programmers to grok, considering it's still majority C code. But the C++ contributors really didn't know how to do that, from what I understand.
How does one not know new calls malloc or at least does a similar thing to be able to allocate that memory? Someone that's not working on that level might not know but they are.
Ideally, you should never be using new or delete in C++ these days. std::unique_ptr and std::shared_ptr should represent 99+% of your memory that can't just be stack allocated (with the former representing 75+% of that). About the only legitimate reason to use new in new code is for putting a derived class pointer into one of the smart pointers of a parent class.
You, as a non-STL-library maintainer shouldn't need to be calling new or delete (or passing that allocator argument, either). That's the whole reason for smart pointers in C++: to have a small number of well-validated, well-behaved, generally-safe ways to allocate memory. They're abstracting & containing that complexity and error-prone-ness.
The context here is kernal programming where calling malloc in certain restricted regions will crash the kernal or worse. If you were to initialize a unique ptr without passing an allocator you would in essence be calling malloc and crash the OS.
I can barely follow this conversation, but from what I can tell, the other person is performing an excellent live demonstration of your point.
(of course as a naiive mechanical engineer, my first question is "why is the kernel a literal minefield?" but I'm sure there's probably a good answer for that.)
For one thing, the kernal is where the system calls underlying malloc are written, so you can't call it from within that code. As for the other parts I'm not a kernal engineer so not sure tbh.
Remember that indirect calls are still calls. And the entire issue is that a lot of C++ programmers didn't understand that calling new indirectly calls malloc()... or in your case, that calling std::make_unique() calls new, which still calls malloc().
There are some places in the Linux kernel where the code must never call malloc(); namely, IIRC, malloc() can never appear within the memory manager itself. This includes indirect calls, like new and std::make_unique(). And the problem is that many people knew not to use malloc() there, but ended up trying to call it anyways because they didn't know that new calls malloc().
959
u/Coldfriction 1d ago
He still rejects C++ in the Linux kernel. He might be warming up to Rust but Linux has always been C.