A 2024 Discussion Whether To Convert The Linux Kernel From C To Modern C++

[furtadopires]

Does this proposal detailed how they're going to murder Torvards first too? Because that's the only way I imagine this being acceptable

Personally I'm 100% in favor of Rust (or any similar/"better" alternative) in case they're really serious about rewriting the kernel since I already had too many problems with memory management using C++ made software.

But I'm far from the level of a kernel developer, then I trust that whatever decision they make in the end It'll come from people with actual technical experience, rather than the average fanboy poster.

[sdack]

Isn't GCC changed to C++ too?

No, not really. It is still a long way for them and I doubt they will ever go fully C++. They merely switched to using a few C++ language features over the traditional C language, because many compilers offer these features, but the code is far from being fully object-oriented in design and from making use of the full feature spectrum of C++. GCC is still very much C source code at heart.

[gufide]

I prefer Rust in terms of cleaner code. You don't have automatic garbage collection tools in C++ and this can contribute to more runtime errors. With Rust's tools you can see when something is wrong due to compilation errors. So the proposal for C++ is missing on the human factor and this is introducing more manual errors, which can hardly be afforded in a kernel with a growing complexity. Fact is C++ requires more time and care unlike rust. Rust is also extremely helpful when reverse engineering by the way.

unique pointers and shared pointer is a form of garbage collection.

[AlanTuring69]

I can't imagine the kernel ever using OOP or any of the C++ runtime incl. shared/unique pointers, but getting away from the unholy disgustingness that are preprocessor macros would be amazing and being able to pass around references is not something to scoff at. To be honest, it would be great to see those features added into C itself.

unique pointers and shared pointer is a form of garbage collection.

They're a form of memory management but not typically considered a form of garbage collection, which is reserved for when languages use heaps etc and clean them up when the language feels like it. You could be pedantic, of course, but shared pointers are considered reference counting with no garbage to collect and unique pointers are definitely not reference counted or anything similar.

[gufide]

With C++ is just so easy to end up tangled in your own complexity. Inheritance and virtual functions is a very good way to end up like that. Exceptions too.

Simple templates and concepts can be fine since it can replace complicated macro code for simpler template code. std::span is actually one of the nicest container right after std::vector and std::array.

I bet many things the kernel is doing could be done at compile time, or just a constant with a comment explaining how that number was obtained could be replaced by a constexpr/consteval function. There's plenty of nice things C++ could bring, but also plenty of horrible stuff.

[hsci]

I hope this will be accepted.

C++ provides many features benefiting security e.g. strong typing, smart-pointers, a lot defined behavior for sequencing, templates (replacing macros) and a string type. I've seen already C projects starting first with minimal adaptions and switching to C++ just for this. There is no requirement to use complicated features like classes, inheritance and exceptions.

And the C++ - is actively developed and improved. Herb Sutter (CPP2) and Bjarne Stroustrup are welcoming safety improvements. Therefore I hope C++ will introduce an optional memory safe mode similar to Rust, maybe with keywords like #safe and #unsafe or legacy mode. The people behind C are enforcing legacy compatibility and have their reasons. C++ can provide both, modern compilers can guarantee defined behavior as we see it with Rust already. As far as I know some existing code and optimizations rely on undefined behavior and hardware programming (like with Rust) requires unsafe code anyway.

I think C++{24,25,26} must add memory safety as language feature. Please note, memory safety isn't magic and will not suppress programming errors.

[bob l'eponge]

I agree with you. I'm an advanced C++ developer, and a junior Rust developer. I enjoy the latter more than the former, even through you can do the same with both languages and probably with similar complexity.

However, even Rust isn't the panacea due to the huge compile time for static checking and the difficulty to change a trait/interface later on for maintenance. I consider modern C++ (with concept, auto, constexpr/eval and template, RAII) and Rust almost the same in features and readability and usability.

It's probably easier to convert a Rust developer to C++ (the concepts are the same) than it is to convert a C developer to Rust, IMHO. The issue is in converting a C developer to C++ that's not just a "using template on C code". There's a shift in thinking how you arrange your mental model of the code and it's too easy to write bullshit C++ for a C developer that'll compile but be unmaintainable.

In all case, I'm sure it's not going to change soon for Linux.

[Weasel]

No, not really. It is still a long way for them and I doubt they will ever go fully C++. They merely switched to using a few C++ language features over the traditional C language, because many compilers offer these features, but the code is far from being fully object-oriented in design and from making use of the full feature spectrum of C++. GCC is still very much C source code at heart.

That's how all C++ code should be.

[hsci]

Isn't GCC changed to C++ too?

https://lwn.net/Articles/542457/

A decade ago. Linux is actually late in following.

[bob l'eponge]

unique pointers and shared pointer is a form of garbage collection.

Good example of what you can't do in a kernel: You can't implement the later in a kernel since it relies on mutex for incrementing the (hidden) reference counter they are using. unique_ptr are the only viable option.

Anyway, if it had to happen, no STL will be in the kernel (it's too large to support and too volatile), so only few major STL concepts (not C++ concepts) could be ported (like unique_ptr, move, forward, lambda, ...)