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

[piotrj3]

I politely disagree. These days any proper C code base can be compiled with a decent C++ compiler. The trend is "going away from C". The prime time of C is over. The current exodus of C programmers towards rust or other programming languages is obvious.


Yes, C compilers are simpler - I've done some myself. But you're mistaken about the results. C++ programs express intent more directly, therefore compilers can optimize better. I allow that C can score a win in some trivial benchmarks. But a C++ compiler is able to produce smaller code that runs faster "most of the time". Don't forget the "optimizing by programmer" aspect. Choosing the right algorithm has a much higher impact than lower level optimizations. The expressiveness of C++ makes it easier to select the right algorithm.


That's an old trope. Assembly output is far less important these days. When I started writing my first C programs (back in the 1980's of last millennium) it was absolutely necessary to check the assembly output of the compiler to catch compilation errors. These times are fortunately long gone. But you miss the key point of the C programming language: C was invented to replace assembly language with something more portable. There have been various attempts to rewrite assembly portions of the Linux kernel in C. In my experience, the compiler's assembly output was always at least as good if not better than my own assembly code. The idea of "you have to write it in assembly to get maximum performance" is outdated. There may be places where some specialists can squeeze out a few cycles - but that's not something for the everyday programmer.


First thing is you need to be willing to learn. The world (and this forum) is full of people that try to bash C++ by ascribing to it a complexity that it does not have. Compare apples with apples. What is described in the whole K-R book is covered in roughly the first chapter of the TC++PL. The sizes of this first chapter and the whole K-R books are very comparable. The rest of TC++PL is about the standard library. Most of the described concepts go far beyond anything in the K-R manual. It is possible to write C++ code without the standard library. The same way as you can do that in C.


I don't get what you're trying to say. Style-guides are not "properties" of the language. Talking about bloat, look at the python standard library: that is bloat. They just call it "batteries included" - and the whole world falls for it.
It is absolutely possible and perfectly legal to write a meaningful C++ program without any style-guide. They tend to pop up in projects where many people have to work together. And they're not always useful. Looking at google for a style-guide is the first mistake. They write down a lot of unnecessary stuff in there. But that's google. There are many shorter C++ style-guides out there if you insist on using one. I can't see that the python style-guide is in any way "shorter" or more compact. And don't forget there are also many more or less bloated C style-guides out there.


Again, I can't make out what you want to say with this. It seems to me that you, on one hand, have not seen enough C#, Java, rust or C++ code to claim that C++ syntax is never used somewhere. And on the other hand you express the idea of "standardizing" or equalizing "most modern languages". As intriguing this idea may sound - this will never happen. And I'm pretty glad about that, it allows projects like rust. Despite my criticism of the language, a fresh look into ism's you've grown accustomed to is always good.
It's pretty clear that there are some people that don't like C++ syntax. As there are people that don't like C# syntax or rust syntax or python syntax or whatever syntax.

First, I wrote Java and Python code commercially. In really big projects on top of that. C# i wasn't writing myself but i was assisting developers writing C#. I have no problem reading Java code. I have no problem mostly reading Rust code (except maybe sick one liners that do a lot of things), I do often have problems reading C++ code. Like every time you use smart pointer you bloat code with <> endlessly. But in other languages you wouldn't use those <> that extensively.

Second, from one side batteries included but i do not agree entirely with it. In my opinion one of the features of good language is if you have to do something potentially shooting you in foot you should be quite explicit. It is opinion you might disagree with it, but when error happens in C and you track down which line crashes most of time (not always) you see ah yea makes sense stupid me. In Rust you would have to explicitly use unsafe. Garbage collected languages will be doing a lot of responsibility for you and will take out gun from your hand.

Third. C++ without most std features is very lacking. Like to use modern C++ you need to use smart pointers. But smart pointers are part of std. And at that point i totally disagree with you. By example Java with just the most basic library (let's say using files/input/output) and Java using more standard library like maps, hashmaps and many other stuff and in principle code changed very little. You can look at C code written for microcontrollers, for kernel and for userspace, and sure some libraries are different but in principle things will change very little (like malloc vs kmalloc etc.). You will understand code (just not understand platform specific stuff). Modern C++ when you can use either std or boost or Qt stuff, and C++ embedded/for kernel will be entirely 2 different worlds.

Forth. You can compile C code as C++ code but you cannot compile C++ code as C code. And when Astree supports subset of C++ (and only up to C++17, none C++20 stuff), in C you have big collection of options, like Frama-C, Misra-C, Astree, you have even Compcert C compiler that is formally proven entirely. Rust already has Ferrocene compiler despite being fresh language and MIRI.

About style guides - i am talking about style guide from same company - google. Google has python style guide. It is both shorter and way more expressive then C++ one (and python gives long code examples. C++ is longer and not even verbose. By giving Python style guide from somewhere you compare apple to oranges.

"That's an old trope. Assembly output is far less important these days." - Linus still cares about it.

Personally for me, I have no reason to use C++. If I write userspace without extreme requirements for performance, i will use Go. Simple easy safe great concurency. If i have to be that performant - Rust. Kernel - Rust is good. And if i have to be extremly performant (like dav1d class performant, database performant) - sorry you have to write assembly and use probably C to interact with it.

[lowflyer]

You need to explain this a bit more, because if anything are AIs too creative. AIs are being used to create literature, graphics, and movies for example. AIs, once trained, produce new data that often is not real, known as hallucinations, but which is derived from the training data. It can turn out to be real, meaning, an AI found something real we have not discovered yet, but it can also be plain false (see various lawsuits against AIs). In any case, AIs are very creative tools. So I do not understand how you think they lack creativity.

My own opinion on AIs is that they lack precision and discipline. Even when trained well require AIs supervision by humans to make sure their creativity does not get out of control. The biggest problem with AIs right now is that we do not have enough data to feed into them, while AIs can pump out a near-infinite amount of nonsense.

Let me try to explain. It depends on how you define creativity. These days, "anything that was not yet here" is classified as "creative". It sets the bar to the lowest possible point. I'd say it's not very creative. Unfortunately the media today is flooded with it. People get de-sensitized and consume.
The human mind is actually quite an excellent tool to distinguish the rubbish from the really creative stuff. With a bit of effort you can train your own mind. Do the following "exercise":

• Choose one of the AI engines. It does not matter which one but the point is easiest to prove with art engines
• Let it create a "work"
• Repeat it. Let it do something different. Repeat at least 50 times
• Watch, observe and read the "works" that AI has created

After the initial excitement has faded away, I guarantee that you'll start to find the "created works" more and more boring. It will get to the point where you start to recognize these "artificial works" on first sight. It's the missing creative input that makes these works boring. No amount of precision or discipline can "fix" that.

This is much less likely to happen with the works of a real artist.

These engines are quick to create "a melange" of existing works. They don't "create" something really new. The "newness" is only in a new combination of existing works. However, human "input" or the "use" of the AI by a human can put the lacking creativity into it.

[darkonix]

I politely disagree. These days any proper C code base can be compiled with a decent C++ compiler.

Did you read the link on https://www.phoronix.com/forums/foru...8#post1435008? It is not trivial for complex codebases like the Linux Kernel and probably most big older projects.

[lowflyer]

</snip>
I do often have problems reading C++ code. Like every time you use smart pointer you bloat code with <> endlessly. But in other languages you wouldn't use those <> that extensively.

Reading any programming language requires practice. It seems to me that you're just allergic to <>. some other guys are allergic to ^ in C#, others are allergic to ~ in shell, others are allergic to $ and still others to [] or ${} ... take your pick. And why do you praise rust that uses <> too? What you express with these pointy brackets <> requires extra keywords in most other languages. So, where is the bloat? And no, smart pointers don't "bloat" code.

</snip> In my opinion one of the features of good language is if you have to do something potentially shooting you in foot you should be quite explicit. It is opinion you might disagree with it, but when error happens in C and you track down which line crashes most of time (not always) you see ah yea makes sense stupid me. </snip>

If you're afraid of the gun that shoots your foot, stay far away from C, don't use the C subset of C++ either and never use "unsafe" in rust. I think you're referring to C++ compilers from two decades ago. These days, both GCC and Clang are very good at pointing exactly to the problematic locations in your code.

Third. C++ without most std features is very lacking. Like to use modern C++ you need to use smart pointers. But smart pointers are part of std.

Any programming language is lacking without their standard library. C is lacking even with their standard library. In modern C++ you don't have to use smart pointers. You can use pointers like in C - and there are many cases where this is the right thing. But you'd be stupid not to use the features that smart pointers offer.

And at that point i totally disagree with you. By example Java with just the most basic library (let's say using files/input/output) and Java using more standard library like maps, hashmaps and many other stuff and in principle code changed very little. You can look at C code written for microcontrollers, for kernel and for userspace, and sure some libraries are different but in principle things will change very little (like malloc vs kmalloc etc.). You will understand code (just not understand platform specific stuff). Modern C++ when you can use either std or boost or Qt stuff, and C++ embedded/for kernel will be entirely 2 different worlds.

I understand you saying "it's much easier to read C than C++". I suspect that you miss one important point: The expressiveness of a language. How difficult is it to detect in a given C code snippet that a (possibly nested) loop does an e.g. inner product? In C++ you are literally writing "inner_product()". In C++ you read it directly from the code while in C you need to "know" how things are done.

Forth. You can compile C code as C++ code but you cannot compile C++ code as C code. And when Astree supports subset of C++ (and only up to C++17, none C++20 stuff), in C you have big collection of options, like Frama-C, Misra-C, Astree, you have even Compcert C compiler that is formally proven entirely. Rust already has Ferrocene compiler despite being fresh language and MIRI.

I fail to see how useful it would be to compile C++ as C. Safety-critical applications are not a normal use case. All the tools you mention are also available for C++ in some form or another. Have you heard about the Joint Strike Fighter Air Vehicle C++ Coding Standards. Yes, safety critical code in C++.

About style guides - i am talking about style guide from same company - google.
</snip>
By giving Python style guide from somewhere you compare apple to oranges.

I did not pick "from somewhere". I picked as "official" as possible: the python stile-guide is from the python documentation on their website, the C++ style-guide is from Bjarne Stroustrup (the creator of C++) You picked a company to prove your point. I don't think google is a good reference for anything. Isn't this exactly what I said earlier: you don't have to use a specific style-guide for C++ if you don't want/need?

</snip> - Linus still cares about it.

That's one person living off past merit.

Personally for me, I have no reason to use C++. If I write userspace without extreme requirements for performance, i will use Go. Simple easy safe great concurency. If i have to be that performant - Rust. Kernel - Rust is good. And if i have to be extremly performant (like dav1d class performant, database performant) - sorry you have to write assembly and use probably C to interact with it.

You're absolutely correct in choosing the programming languages you're most fluent in. There's nothing wrong with that. Don't get me wrong. I have nothing against any programming language. I just find it quite amusing how many that are rejecting C++ are now jump on the rust bandwagon.

With the performance I disagree. You don't need to fall back to assembly for extremely performant code. You don't need C to interact with assembly from C++. And this is the second time that somebody suggests to me to rewrite dav1d in C++.

[piotrj3]

Reading any programming language requires practice. It seems to me that you're just allergic to <>. some other guys are allergic to ^ in C#, others are allergic to ~ in shell, others are allergic to $ and still others to [] or ${} ... take your pick. And why do you praise rust that uses <> too? What you express with these pointy brackets <> requires extra keywords in most other languages. So, where is the bloat? And no, smart pointers don't "bloat" code.


If you're afraid of the gun that shoots your foot, stay far away from C, don't use the C subset of C++ either and never use "unsafe" in rust. I think you're referring to C++ compilers from two decades ago. These days, both GCC and Clang are very good at pointing exactly to the problematic locations in your code.


Any programming language is lacking without their standard library. C is lacking even with their standard library. In modern C++ you don't have to use smart pointers. You can use pointers like in C - and there are many cases where this is the right thing. But you'd be stupid not to use the features that smart pointers offer.


I understand you saying "it's much easier to read C than C++". I suspect that you miss one important point: The expressiveness of a language. How difficult is it to detect in a given C code snippet that a (possibly nested) loop does an e.g. inner product? In C++ you are literally writing "inner_product()". In C++ you read it directly from the code while in C you need to "know" how things are done.


I fail to see how useful it would be to compile C++ as C. Safety-critical applications are not a normal use case. All the tools you mention are also available for C++ in some form or another. Have you heard about the Joint Strike Fighter Air Vehicle C++ Coding Standards. Yes, safety critical code in C++.


I did not pick "from somewhere". I picked as "official" as possible: the python stile-guide is from the python documentation on their website, the C++ style-guide is from Bjarne Stroustrup (the creator of C++) You picked a company to prove your point. I don't think google is a good reference for anything. Isn't this exactly what I said earlier: you don't have to use a specific style-guide for C++ if you don't want/need?


That's one person living off past merit.


You're absolutely correct in choosing the programming languages you're most fluent in. There's nothing wrong with that. Don't get me wrong. I have nothing against any programming language. I just find it quite amusing how many that are rejecting C++ are now jump on the rust bandwagon.

With the performance I disagree. You don't need to fall back to assembly for extremely performant code. You don't need C to interact with assembly from C++. And this is the second time that somebody suggests to me to rewrite dav1d in C++.

I will only think about last point. Compilers cannot use effective way vectorization instructions. Dav1d has a ton of ASM code written.

Just by example (fastest any lang vs fastest hand written asm/unsafe) execution times
Franken redux 7.21s vs 2.1s
n-body 3.92s vs 2.08s
spectral norm 0.71s vs 0.4s
mandelbroot 1.01s vs 0.88s

(Later on benchmark game there are some algos that don't benefit from handwritten assembly, BUT video codecs are entirly made in mind that they can be decoded efficiently in hardware and are supposed to be performant, and they benefit a ton from handwritten assembly).

And about safety every big programming language has some guidelines for safety or safer programming. The question is:
- is number of rules sane? Eg. Can you remember all those rules in your mind or on every code review you spend long time with book by your side?
- can those rules will be automatically checked?

The problem isn't even can you do it - because answear is yes you can. You can use even javascript in cosmos. The problem is using that stuff is by cost feasable? Are those new features helping us decrease cost (because it resolves some problem) or increase cost because guidelines take longer to make, because code needs more time to be checked against guidelines and programmers need more time to learn it and polish their skills.

And here is a problem. C++ is too complex. Proving absence of errors in C++ compiler is not practically possible but possible for C (compcert C compiler is formally proven), programmers are humans and would need to know a lot "richer" language, the less explicit usage of certain stuff give you always a question if there is a bug as side effect of stuff you are doing.

C++ compiler situation shows especially problematic side of C++ - there is only one compiler that supports all C++20 features and it is MSVC. And there is not a single C++ compiler supporting C++23 all features. Like remember when Linus was annoyed by compiler bugs in GCC? Guess how annoyed he will be with C++!

Seriously speaking I wouldn't mind if C++26 or some new standard will be deprecated/outright removing certain past features from language. I believe it would make compilers simpler and make language better by default to avoid certain pitfalls.

[ssokolow]

I will only think about last point. Compilers cannot use effective way vectorization instructions. Dav1d has a ton of ASM code written.

I think the problem is that it hasn't been made clear where compiler intrinsics exist in this discussion. On the one hand, it's agreed that Auto-vectorization is not a programming model but, on the other hand, compiler intrinsics are apparently sufficient enough that MSVC chose to disallow inline assembly for 64-bit targets.

[lowflyer]

I will only think about last point. Compilers cannot use effective way vectorization instructions. Dav1d has a ton of ASM code written.

I know. I had a close look to that code because some people suggested to me to rewrite it in C++.

Just by example (fastest any lang vs fastest hand written asm/unsafe) execution times
</snip>

I think you generalize too much. There are areas where assembly is faster. This is not the normal case. But this is something that is "for the specialists".

</snip>
... because code needs more time to be checked against guidelines and programmers need more time to learn it and polish their skills.

Have you ever heard of static code checkers? Writing code today without them is just stupid. These days and IDE has support for them. They will highlight every guideline to the programmer even before the compilation. No need for a book on the side.

And here is a problem. C++ is too complex. Proving absence of errors in C++ compiler is not practically possible but possible for C
</snip>

You are completely wrong on this point. Proving absence of errors (qualified code) can be done with every programming language. It's a tedious, difficult and manual process. The choice of language has an influence but it is a well specified process that has to be done on top of any tools you use. It's how it is done in aviation. It is not something that comes out of a special compiler. The tools you mention (Compcert, Astree, etc) are only tools that help in that process by providing documentation templates and by being qualified themselves. Code that is already qualified doesn't need to go through the process again. Just remember the JSF software is written in C++.

I think we're running in circles. On one hand you want assembly like performance on the other you want the compilers to prove absence of errors. Where is that assembler-compiler that qualifies the code? You're asking for something that does not exist.

C++ compiler situation shows especially problematic side of C++ - there is only one compiler that supports all C++20 features and it is MSVC. And there is not a single C++ compiler supporting C++23 all features. Like remember when Linus was annoyed by compiler bugs in GCC? Guess how annoyed he will be with C++!

Seriously speaking I wouldn't mind if C++26 or some new standard will be deprecated/outright removing certain past features from language. I believe it would make compilers simpler and make language better by default to avoid certain pitfalls.

Well, you have overlooked that GCC also supports all C++20 features (With the exception of modules which is not completely supported by any compiler) Another serious misconception: You don't need to wait until a standard is complete before you can use it. We've used C++11 before it was complete, we did directly jump to C++17 and used it before it was complete and are now using C++23 despite it is not complete. It's the same as with *any* C++ feature: Use it when you need it - don't use it when not.
The situation is not much different in rust. (e.g. What is the correct threading library to use? Is the tokyo code the correct one?) There have been C++ features deprecated and removed. And there will be more.

[darkonix]

Maybe you are just stupid? OOP in c++ has no baggage unlike java. When an object is at the end of its life it is cleaned up no matter in which scope its created so you dont have to worry about calling free a dozen times in random places. Secondly if you use for example std::array you can guarantee bound checks when accessing an array, if you dont need to just continue using c array. Where are the downsides? If using c++ correctly you are simplifying code and making it safer. Where is the increase in complexity?

That's only true if you followed best practices everywhere. C++ still allows you to cause memory leaks, double frees, etc. and cause security vulnerabilities. Even if you use the STL there are some use causes that inadvertently can cause issues. The programmer stills need to own that.

[cj.wijtmans]

That's only true if you followed best practices everywhere. C++ still allows you to cause memory leaks, double frees, etc. and cause security vulnerabilities. Even if you use the STL there are some use causes that inadvertently can cause issues. The programmer stills need to own that.

thats why i LIKE C++. And that is why it would be relatively easy to switch to the C++ compiler and then make new code use C++ features. Or even cuse objects where before it was just a typedef. Also allowing "unsafe" code makes custom allocators easy to implement.

[ssokolow]

thats why i LIKE C++. And that is why it would be relatively easy to switch to the C++ compiler and then make new code use C++ features. Or even cuse objects where before it was just a typedef. Also allowing "unsafe" code makes custom allocators easy to implement.

darkonix's phrasing was less than idea. Rust lets you do all those things too with the unsafe keyword... it just also reliably catches situations where you didn't want to do those things.

...like how C++ will catch various nonsensical operations on various data types while assembly won't.