A 2024 Discussion Whether To Convert The Linux Kernel From C To Modern C++ (phoronix.com) 139
serviscope_minor shares a Phoronix post: A six year old Linux kernel mailing list discussion has been reignited over the prospects of converting the Linux kernel to supporting modern C++ code. The Linux kernel is predominantly made up of C code with various hand-written Assembly plus the growing work around supporting Rust within the Linux kernel. While it's not clear yet if there's sufficient weight to make it a reality, a Linux kernel mailing list discussion has been restarted over potentially seeing the Linux kernel C code converted to C++ in the future.
Back on 1 April 2018 was a set of 45 patches by Red Hat engineer David Howells to begin converting the kernel to C++. This would allow the mainline kernel to make use of inline template functions, inline overloaded functions, class inheritance, and other features not currently supported by the Linux kernel with its C code. A bit hard to make serious discussions that day and ultimately the patches resided on the Linux kernel mailing list for six years without much discussion. serviscope_minor adds: It is notable that the current discussion is somewhat different from the infamous discussions in the past.
Back on 1 April 2018 was a set of 45 patches by Red Hat engineer David Howells to begin converting the kernel to C++. This would allow the mainline kernel to make use of inline template functions, inline overloaded functions, class inheritance, and other features not currently supported by the Linux kernel with its C code. A bit hard to make serious discussions that day and ultimately the patches resided on the Linux kernel mailing list for six years without much discussion. serviscope_minor adds: It is notable that the current discussion is somewhat different from the infamous discussions in the past.
Maybe Rust would be a Much Better Choice (Score:5, Insightful)
The problems with C++ are pretty well known. If the community is going to do wholesale change, moving to a language that offers much more support for formal verification, better type-checking, and overall better security, seems to be a better -return on investment-.
That being said, I generally don't like the idea of 'recoding working software', the likelihood of introducing new bugs outweighs the putative arguments for "easier to maintain."
Re:Maybe Rust would be a Much Better Choice (Score:5, Informative)
The problems with C++ are pretty well known. If the community is going to do wholesale change, moving to a language that offers much more support for formal verification, better type-checking, and overall better security, seems to be a better -return on investment-.
That being said, I generally don't like the idea of 'recoding working software', the likelihood of introducing new bugs outweighs the putative arguments for "easier to maintain."
In most cases, I'd agree, but not in this one. The main reason is it's not a wholesale change. The patch set to change the kernel from C to the intersection of C and C++ is pretty small, at which point the kernel is now as much C++ as it is C.
The benefit is that at that point, C++ only features can be introduced piecemeal without any grand rewrite or recoding. Got a new enum? Make it an enum class. Need a new ops table? Use an abstract base class. Need an init function for a struct to set up its invariants? Make it a constructor.
Re:Maybe Rust would be a Much Better Choice (Score:5, Insightful)
Getting the Linux kernel to compile using a C++ compiler is a considerably different activity than switching the language of the kernel to C++.
I'm in the middle of trying to figure out how to fix bugs in an old C++ MFC program that does real-time communications. These are my current problems with C++:
1. Estimating the performance of C++ code. For example, what does a simple statement like A = B do? In C, you can kind of answer that question. In C++, anything can happen. I have debugged libraries that specifically say A=B will not leak memory, and it does.
2. Which version of C++? The C++ standards committee has been really busy lately ...
3. Unlike the preprocessor, the template generator does not dump in the intermediate C++ code. One of the nice features of the C preprocessor was that if you didn't understand what it was doing, it could dump its output as C code. The MS C++ compiler generates a small book of error messages if I goof up type indications when using templates, and those messages don't clearly suggest a fix.
4. If you are trying to do solid, multi-threaded, real-time code, C++ doesn't help you. It doesn't stop you. But it doesn't help you either.
5. If you are still trying to do multi-threaded code, and follow the entire shared_pointer (not thread safe), atomic_shared_pointer (slow, possibly locking), hazard pointer (lock-free), fast shared pointer over hazard pointer discussion (multi-threaded and lock-free), then you realize two things:
(a) this is a new way to do garbage collection (C#/Java), and
(b) the new fast hazard / shared pointers are too new to be in the C++ library!
5. It's almost impossible to write readable C++ code without a style guide. The style guide will always be out-of-date. How do you enforce the style guide on a project of the size, scope and age of Linux? or any other long-lived project?
6. Correctness: how do you analyze code correctness in C++?
(a) It is not obvious what any given statement does.
(b) It is not obvious what the maximum execution time of a block of code is.
(c) It is not obvious that any given pointer is valid.
(d) It is not obvious that smart pointer accesses are wait-free.
(e) Even if you get all of your pointers to be valid, it is not obvious that libraries won't create indeterminate state or suddenly call exit(). This is a real problem. We have user complaints like "I clicked on this button to enter a number and the program disappeared." We traced it to a library, which does something, which does something, which has an error condition, and terminates in an exit(). Our program is a real-time control system. It can't give up and call exit().
(f) For long-lived applications, C++ works great as long as you can guarantee the program can handle all of the exceptions that it can throw. Does C++ help you do that? Can I even get a listing of all of the unhandled exceptions? or which exceptions are handled where?
(g) Real-time control systems need to execute in finite memory. Much of the C++ library assumes that an unlimited heap is available.
7. Would it be too much to ask for a safe array type? Something that handles a[-1] gracefully? My PLC structured text [wikipedia.org] compiler throws error messages if I even enter such a thing. It will never cause a GPF on an invalid array access. What standard data type in C++ does something similar?
8. Can we have a safe multi-threaded variable length array type, please?
Is C++ even the correct language for a large program like the Linux kernel?
Re: (Score:2, Insightful)
Getting the Linux kernel to compile using a C++ compiler is a considerably different activity than switching the language of the kernel to C++.
It is not. If it compiles with C++, it is C++.
1. Estimating the performance of C++ code. For example, what does a simple statement like A = B do?
What does some_func(A, B), or worse SOME_MACRO(A, B) do in C?
2. Which version of C++? The C++ standards committee has been really busy lately ...
They've been releasing every 3 years on schedule, about 2x as fast as C. So w
Re:Maybe Rust would be a Much Better Choice (Score:4, Informative)
1. Estimating the performance of C++ code. For example, what does a simple statement like A = B do?
What does some_func(A, B), or worse SOME_MACRO(A, B) do in C?
Tells you, the reader of the code, that what's happening may be complex. In C you can expect that a=b is a simple, computationally inexpensive operation.
Re: (Score:2)
Re: (Score:3)
Did you mean `a==b`?
Both share the same problem in C++
Re: (Score:3)
The absolute most that happens in C is a memcpy().
C++ can run thousands of lines of code, even shell out to the operating system and await a result, all in that simple little a=b.
Re: (Score:2)
You're using crap libraries. You can't have a debugged library which has memory leaks. MFC enforced horrible coding standards mainly because it had an eventing model which was junk. And on a modern CPU, all of the cases you made for real-time systems an C++ are irrelevant because the CPU itself will interfere more with the code you write tha
Re: Maybe Rust would be a Much Better Choice (Score:2)
That you don't know what a = b is a big trap for newer developers in many languages.
In some newer languages than c++ even bigger as the thing defined in the class as a boolean can be observed without it being obvious in the class you're editing.
Re:Maybe Rust would be a Much Better Choice (Score:5, Informative)
OK double replying, but if you have the time:
https://www.youtube.com/watch?... [youtube.com]
It's an excellent video from Matt Godbolt (of compiler explorer fame) where he takes some very hacky C code from 25 years ago and piecemeal upgrades it to C++, in order to resurrect the project.
Another example is GCC which has switched from C to C++ in the typically conservative GCC fashion.
Re:Maybe Rust would be a Much Better Choice (Score:4)
You're presenting gcc guide as some massive gotcha, haha look how C++ sucks or something.
The guidelines fall into 3 general categories.
1. It's C legacy. That includes no RTTI, since GCC already had an RTTI framework in C and yes it is wasteful having two old them. It also includes the lack of exception safety. C++ doesn't make old C code magically better, it simply allows you to improve it over time. The expectation is that new code is written to be exception safe so exceptions can be gradually introduced in future.
2. Engineering tradeoffs. Multiple inheritance falls into this category. It's a powerful tool in specific, quite rare but important cases. I don't see why it's funny that C++ provides tools that you don't need often but really help in certain cases. No language relieves you from the need to use good taste in design, and not misuse the provided tools.
3. Things that were the case is C, so are not in anyway worse and ultimately don't matter. The compiler already aborts on an ICE. what else do you do when your invariants are broken? I'm also mystified as to what you'd expect a less funny language to do at the same point.
Re:Maybe Rust would be a Much Better Choice (Score:4, Insightful)
Re: (Score:3)
Re:Maybe Rust would be a Much Better Choice (Score:5, Interesting)
The problems with C++ are pretty well known. If the community is going to do wholesale change, moving to a language that offers much more support for formal verification, better type-checking, and overall better security, seems to be a better -return on investment-.
I think what actually matters are the effective constraints imposed by systems such as proof assistants and static analysis systems rather than the underlying language. As these systems change and evolve what the programmer can do or at least get away with doing with confidence evolves with them. This is ultimately a better approach than fixed schemes like rust which impose a fixed set of constraints.
That being said, I generally don't like the idea of 'recoding working software', the likelihood of introducing new bugs outweighs the putative arguments for "easier to maintain."
It's more like you change a compiler flag and maybe some small bits of code and all of the sudden you have access to a whole set of new functionality that you can elect to use or not.
Re: (Score:3, Insightful)
Rust has been considered and it's part of the LKML discussion. Perhaps reading that would be instructive.
Rust is not the end-all be-all of "safe" computing, and modern C++ has many many more advantages,
chief among which is that it can compile existing C code.
I do agree that "if it ain't broke don't fix it" BUT if someone wants to put the effort in to recode twenty-year
old C code into modern C++ and in so doing remove some inline assembly and other cruft, those are noble
(and lofty) goals and I wouldn't stop
fun thought experiment (Score:5, Funny)
Then ask it to convert it to ADA.
Re: (Score:3)
True story: A friend of mine worked on a government project in the mid 1980s where they had to write a compiler for a bespoke specialty programming language.
The compiler had to be written in COBOL.
Re:Maybe Rust would be a Much Better Choice (Score:5, Insightful)
C++ has problems, yes, but it's time tested. Rust is not. Rust at the moment has too many people proselytizing it, like apostles. The majority of those apostles do not list any drawbacks to Rust, and to me that's a red flag.
As for C vs C++, the snag here is that once they go thte C++ route, it opens to the door to all the bad C++ styles that lead to code that is bloated and slower. Too much in C++ is hidden behind the scenes; a simple line of code might not actually be simple behind the scenes and instead result in something far more complex than was intended. Even a simple assignment might have copy constructor functions being called. Expert C++ programmers understand this though and they know how to avoid the pitfalls; but there are plenty of average C++ programmers who program for rapid-prototyping rather than for efficiency and reliability. With C, unless you're doing a lot of complex macro expansion, simple source code results in simple object code.
There are people who do low level code in C++. To do so they usually turn off features (ala Embedded-C++ standard); turn off run time typing and exceptions, eschew templates, and encourage namespaces and static classes.
In case you think C++ is too bloated for the kerne (Score:5, Interesting)
This was a fascinating talk by Jason Turner a few years ago on the features of C++17 that generate very efficient code, but bring a lot of power and expressiveness to the programmer. In the talk he creates a tiny game for a Commodore 64 using modern c++17 including templates. Quite eye-opening about how powerful modern compilers are, and how good C++ has become. It's a lot simpler than it used to be, and it's quite efficient. In fact in the demo talk, there was zero overhead to all of the language features he used.
https://www.youtube.com/watch?... [youtube.com]
I've spent the last month working on a project in C++ with Qt and I have to say it's been a very pleasant experience. Just wish Qt would move their signals mechanism from runtime string comparison to a template-based approach. A couple of devs showed it can be done with their now-dated CopperSpice fork of Qt.
Re: (Score:2, Insightful)
Re: (Score:2)
I've only ever been able to tinker in C++ as all my work has been in C and assembler (many variants). But C++ always felt to me like the metaphorical equivalent of handing an M60 machine gun to a rank recruit and saying "push this lever with your finger and it go bang!" - then stand back and observe the results.
My gut has always told me that C++ is SO expressive that any professional development needs strict guardrails of coding standards and careful team review to be successful. Maybe that
Re:In case you think C++ is too bloated for the ke (Score:4, Interesting)
Wow, I didn't realize that - thanks for the C=64 story.
Somebody told me recently I should look at C++20 since all the complaints I had about C++89 (last used in '94) were gone. :)
I suppose linux could choose C++23 as a baseline if they want the best footing for the proposal, though the gcc docs seem outdated as to support.
https://gcc.gnu.org/projects/c... [gnu.org]
Re: (Score:2)
Somebody told me recently I should look at C++20 since all the complaints I had about C++89 (last used in '94) were gone. :)
hough the gcc docs seem outdated as to support.
They're up to date. It's only just turned 2024, and I'm not 100% sure C++23 has even passed the final ISO ratification yet. There's very little not done for C++23, and the not done ones are more administrative fiddles than features.
Re: (Score:2)
My understanding is the committee that writes the standard has been done with C++23 for a while, but it hasn't made it way through all the administrative steps to be finalized.
It doesn't really matter though, as compilers don't fully support C++20 yet. Full compiler support is always years behind the release of the standard. It sounds like modules in particular will take a will to get working well.
Re: (Score:2)
Templates are usually abused by those who can't understand polymorphism and overloading, and leads to the compiler generating a ton of code bloat
Re: (Score:2)
You could level exactly the same criticism at macros, which as it happens the kernel is full of. It's also got lots of polymorphism. It's almost like the kernel developers already know how to make this tradeoff.
Re: (Score:2)
Macros are a simple text replacement. The compiler is going to generate a block of code for every type(s) that you use in a template
Re: (Score:3)
Macros are a simple text replacement. The compiler is going to generate a block of code for every type(s) that you use in a template
Thar's exactly what macros do: they just paste in the code when and where you call a macro, every time. In fact templates were somewhat explicitly modelled on macros but integrated properly with the type system. They can be implemented almost as text replacement and in fact the earlier ones were.
Re: (Score:2)
I love using Qt from Python via PySide 6 for small simple apps. Meaning I can combine things for which there are python modules but not support in the C++ standard library, and without having to use a build system or such. How would signals work with that if a C++ template system was used instead?
Re: (Score:2)
Yes that probably would make python bindings require more glue code. C++ is notoriously hard to interface with from other languages and all the compile-time niceties like templates make that harder.
Re: (Score:2)
Just wish Qt would move their signals mechanism from runtime string comparison to a template-based approach.
Qt signals and slots can change dynamically during runtime, so templates cannot be used in that context.
Re: (Score:2)
Yes and that can be problematic. I've had several occasions over the years when a typo in the connect() line in what appeared to be valid C++ code compiled fine but would only be known as an error at runtime much later. I haven't used GTKmm in quite a few years but I remember it used templates to make sure the the runtime connection calls were type safe and a similar typo would result in a compile error. Pretty sure they use a library called libsigc++.
Plus CopperSpice proves that all of the signals and sl
Re: In case you think C++ is too bloated for the k (Score:2)
Not Rust? (Score:2)
I'm not an OS expert, but I thought there was a push toward Rust, not C++, as Rust is allegedly more modern.
Re:Not Rust? (Score:4, Insightful)
Rust is more modern, for sure (by definition), and brings some really neat things to the table.
With that said, you need a rewrite to get the kernel in Rust, whereas for C++ it's a small patch set and a recompile. You won't get all the benefits of Rust if it switches to C++, on the other hand the latter is vastly easier than the former, since it can happen piecemeal without any grand rewrite or giant patches.
Re: (Score:2)
Okay, I see, so C++ is a better-fitting super-set of C (more backward compatible), compared to Rust.
I wonder if there are any other notable languages that are largely backward compatible with C. Sometimes one can get backward compatibly on "normal" use of a language/tool, but it won't handle obscure or edge cases. If that's the case, then reworking existing Linux C could be relatively minor, unless it relies heavily on the edge cases.
Re: (Score:2)
unless it relies heavily on the edge cases.
It relies so heavily on edge cases and extensions, that it only really works in GCC. On the other hand GCC also has a C++ compiler shares most of the code with the C compiler, so it ends up being OK.
Actually one of the benefits is a fair number of the gcc specific things which are used to make kernel programming easier are available as standard C++ features, so it would make the kernel more portable.
Re:Not Rust? (Score:5, Informative)
Is that just bad coding style, or something that's necessary for OS efficiency?
Mix of reasons. In some case, C (and C++) don't provide a mechanism. One of those is asm, and the GCC variant where you tell the compiler which registers you're fiddling with. The only alternative really is to write the whole function in asm, and call it from C. That would involve a lot more asm code over all, so that's probably a bad choice.
Those (and other things) in turn rely on the precise memory layout of structs, which is technically "implementation defined" behaviour.
Re: (Score:2)
Re: Not Rust? (Score:3)
Anyone up for rewriting the Linux kernel in Zig? :)
Re: (Score:3)
For great justice?
Re: (Score:2)
This does surprise me a bit with all the rust "fans" chiming in, I would think that would be a future direction for Linux based upon what little I know.
But I think the main issue with rust in the kernel (not drivers) has to do with exotic hardware Linux runs on. AFAIK there is no port of rust to those systems. Off the top of my head are the "Super Computers", I doubt they even have a rust compiler.
With that said, time to burn some karma. At this point, Linux seems to be veering off the Open System road
Re: (Score:2)
Re: (Score:2)
The solution then is for Rust devs to fork the kernel and create a new name for their kernel, because if you're rewriting or building it from the ground up it's not the "Linux" kernel anymore.
Code that works well... (Score:5, Insightful)
... should not be "converted", unless you want to start another debugging cycle
The only time old code should be touched is if it has problems
Re:Code that works well... (Score:5, Insightful)
Re: (Score:2)
Case in point. The elevators at O'Hare's long-term parking don't have floor buttons inside, but rather just an open door button and a close door button. To select which floor you want to go to, there's a very small LCD in the middle of the bank of 4 elevators with floors
Re: (Score:2)
I have seen elevators like that in one of the new office buildings in Lithuania. It's OK if I'm the only one there, but I'm sure it would be really confusing if there were many people trying to use the elevators.
Yeah, its stupid.
Re: (Score:3)
... should not be "converted", unless you want to start another debugging cycle
What do you think the conversion entails? It's going from a rather kernel specific dialect of GNU C to GNU C++. Much of the conversion is changing "class" to something that's not a keyword in C++, and a few other related changes.
While there are a few places where ISO C and ISO C++ differ in what is UB, this isn't the case for GCC.
Re: (Score:3)
Agreed about "converting" which is why moving to Rust isn't part of this discussion. Instead, they are talking about upgrading specific areas of problem code where they used C macros to hack-in features that are native to C++ anyway. Also note that "problem" code doesn't just mean buggy code. It can mean code that is hard to debug, doesn't work with modern tools (compilers, static analysis tools), is brittle, isn't type-safe, etc.
IMHO, you do this next time you touch the module, or when you have enough d
Re: (Score:2)
... should not be "converted", unless you want to start another debugging cycle The only time old code should be touched is if it has problems
Which is partially why there is still a lot of COBOL code inside (usually) financial systems. It works, and the basic accounting principals that the code implements have not changed.
Re: (Score:2)
The only time old code should be touched is if it has problems
You're assuming a static world. The kernel is not static, it constantly changes and is constantly being developed. No one here is proposing converting code for no reason. There are actual benefits to this change for the people who are maintaining and developing the kernel.
Also what is being proposed is not a rewrite of the kernel just a few small parts of it.
modula-2 (Score:4, Insightful)
The gm2 compiler is coming along nicely, why not use to that if we're talking about switching the Linux kernel over to a new language. Or why not support 100 different languages at once to maximize our software freedom. I mean other than this being a ton of work with no immediate short term benefit and only a modest theoretical long term benefit.
C is difficult to dislodge because it's not too bad. Just bad enough to upset people but not so bad that there is a crisis that forces a change.
Re: (Score:2)
The gm2 compiler is coming along nicely, why not use to that if we're talking about switching the Linux kernel over to a new language.
How much work is it to switch the entire kernel over to Modula-2? We know what the answer is for C++, because the patch set is in that mailing list thread, and it's not very much.
Re: (Score:2)
It's not just about changing the code... Even if you could change 100% of the code to Modula-2 overnight: you still need to Train all the kernel developers on Modula-2 to the point where they know it just as well as kernel C, and persuade the team of current C kernel programmers that your way is the best way.
Re: (Score:2)
That's still the thing C++ doesn't have. Let's say you switched the kernel from C to C++ overnight. You can do that: the patch isn't big mostly revolves around variables which are keywords in C++, like class. So you switch, and now it's technically a piece of C++ code even if it looks like and behaves like (and compiles like!) C code.
So then you drop compiling as C as a requirement and it's still as it was before and therefore immediately familiar with every C programmer hacking on the kernel.
The point is t
Re: (Score:2)
That is not at all what the topic is about. There is no discussion about "moving to a new language." The discussion is about removing the shackles that forbid using modern syntax. No one is talking about dislodging the C. They are talking about replacing hacky macros with equivalent C++ syntax that is already in the compiler that they are using.
Re: (Score:3)
C and C++ are not the same language. C++ is not a strict superset of C. GCC will by design compile C++ code differently than C. And technically the kernel's C is a slightly different language than standard C.
The differences are small, and probably can be worked through, but they are still quite capable of resulting in bugs.
My main concern though remains that the pool of those who can handle C++ well, including other people's C++, is MUCH smaller than those who think they can. It's a huge language, with
Re: (Score:2)
1. Because using a toy language like Modula-2 is idiotic. C's and C++'s libraries have literally had man years of debugging. Modula-2 has not. Coders know C's idioms, best practices, and how to avoid shooting themselves in the foot. Modula-2 is an yet-another obscure theoretical garbage language. Application is FAR more important than theory or some prof's pet language especially in an OS.
As Bjarne Stroustrup once famously said: [stroustrup.com]
"notable" (Score:2)
"It is notable that the current discussion is somewhat different from the infamous discussions in the past."
But the arguments are not.
Re: (Score:2)
That "infamous" link appears to be Slashdotted, that's the first time I've seen that effect for a large number of years.
Re: (Score:2)
Ok - now I have read it, glorious.
Re:"notable" (Score:5, Insightful)
Now, I'm not advocating converting the Kernel. I am of the camp that thinks, "if it ain't broke, don't touch it." But the arguments made against C++ in 92 aren't applicable anymore. There might be other valid objections, but those will be pertinent to what technology is like in 2024.
Re: (Score:2)
I was primarily a C++ programmer from 1996 to 2010. There have been so many changes to the language since then with C++11, C++17, C++20 and the upcoming C++23 that some of the new code looks like another language to me now. There are some really nice features though that allow the compiler to catch errors or the developer to avoid them, and of course, the compilers have been become so much better in the last few decades (I assume that applies to the C compiler as much as the C++). I'm amazed just how man
Re: (Score:2)
I started working in C++ in 2013, having self-learned + uni c++98 before. Now we're using c++20. It is indeed a completely different language...
And it all works together*, different versions in one source file, no need to set specific versions for specific parts of a project (looking sideways at rust's per-crate versions)
* well, we did have a genius that put "using namespace std;" everywhere, and when std::byte came along, boy what a week...
Re: (Score:2)
Nobody is "scared." Linus raised factual, specific and well-supported technical concerns which were not addressed.
The first red flag is that C++ has "so many changes" while C is just plain ol' fuckin' C. If I'm pulling a wagon I don't need Secretariat. Just give me an old paint and we'll get the crop to market.
Leave it the hell alone.
"Hand-written Assembly" (Score:3)
Re:"Hand-written Assembly" (Score:4, Funny)
No as opposed to asking chatGPT "code me a kernel as though I was amped up on Red Bull and lived on a diet of Cheetos."
Re: (Score:2)
I commented already, so I can't mod parent up +1 funny....
Re: (Score:2)
Mtn Dew and pizza! Sheesh!
Re: (Score:2)
Re: (Score:2)
Replacing the C pre-processor with a more powerful one is how C++ was first created.
C++ allows abuse of epic proportions!
Object oriented code is write once (Score:5, Interesting)
Re:Object oriented code is write once (Score:5, Informative)
And read never. C++ is great for writing code and getting something working fast.
I recommend you read up about ops tables in the kernel, for example in the VFS layer.
It is literally a virtual function dispatch table. And the implementation is that every derived class (a struct) has a const ops* pointer to the ops table. This is exactly how the C++ compiler implements exactly this under the hood.
How is writing "virtual some_func();" worse than manually coding up an ops table?
The kernel already uses OO where appropriate, and nothing about C++ forces you to use OO where it is not.
Everyone who knows embedded C can read the code. In C++ there is now so much to the language and you can layer it so deeply that two competent coders might not be able to read each others code.
That's somewhere beyond hyperbole and out the other side. And the thing is the kernel already undergoes PR reviews, which is why it hasn't degenerated into an oversized IOCCC entry.
Re: (Score:3)
I wish I could mod this up to the moon. I worked on the HP-UX kernel many years ago, and its VFS, I/O, etc. layers and the communication among them was more object-oriented than a lot of C++ code I've seen. You can write object-oriented assembly--it's a discipline, not a set of language features.
Re: (Score:3)
While I like using C++ for a lot of things, it's ability to change what things 'mean' makes it a nightmare for large projects that interact with hardware. Is that a 'plus' sign? Well, is it REALLY an addition, or is there an overloaded function that makes it do something 'sensible'? What type is this? Well, it might be a simple type, or it might inherent from something that inherits from something that brings along unexpected functionality that the compiler 'helpfully' inserts.
For low level stuf
Re: Object oriented code is write once (Score:2)
Half of using C++ effectively is figuring out which of its many features you should avoid using. Operator overloading, outside of a few very specific (and useful!) cases, is one of those.
Re: (Score:2)
Half of using C++ effectively is figuring out which of its many features you should avoid using. Operator overloading, outside of a few very specific (and useful!) cases, is one of those.
It's not so much figuring out what to not use, so much as figuring out when it is and isn't appropriate to use them. If you buck wild with operator overloading, it makes a colossal mess. On the other hand vectors having [] indexing like char* buffers improves readability.
It's like if some programmers were carpenters, they w
Re: (Score:2)
It's like if some programmers were carpenters, they would try and solve every job using only the largest and most powerful table saw in the shop, no matter what.
New Yankee Workshop.
Now, I have to go cut a single dado. Where's my Stanley No 45 plane?
Re: Object oriented code is write once (Score:2)
If you say so mate. Somehow we OO devs manage to alter, update and rewrite code every day despite it all being impossible to read.
WHFO (Score:2)
When Hell Freezes Over.
No need to port Linux to C++ to make it Modern (Score:2)
Just port Linux fom the current ANSI C 11 standard (producen in, well, 2011) to the more current ANSI C 17, and then to ANSI C 23, Instead of moving it to ANSI C++20, with all the potential problems that might entail, and then to C++23
No, Keep Linux in C, as god intended, just bring it closer to current ANSI C Standards at a rapid clip, that should be more than enough to keep it "Modern"
Re: (Score:2)
Yeah, that was my thought.
C++ was historically a 'superset', 'with classes'. If you're talking about using modern C++ then surely some of the good features would be implemented in the latest C standard too.
Likewise I don't see the problem as re-writing it in C++ or Rust or whatever. The strength of Linux over any hobby OS written in a langue-du-jour (pardon my French!) is its hardware support. e,g, Hurd is going nowhere despite a Debian userland. I would see the evolution of Linux into a bunch of experiment
C++ has too many hidden behaviors (Score:4, Insightful)
C++ programs instruct the compiler on how to generate another program, C is much more straightforward. It's a lot easier to read and figure out what's going on, or what could be going on and I think that's a bonus for a kernel.
Also, a rewrite of code that works is always a bad idea. You need to test all over again.
Re: (Score:2)
Have you seen some of the gnarly kernel macros?
Also, a rewrite of code that works is always a bad idea. You need to test all over again.
No one's proposing a rewrite.
Fork, instead of arguing on LKML (Score:4, Insightful)
If it's so easy and healthy to use C++ in the kernel, that means it should be easy to fork.
Let's see how it pans out in practice.
Re: (Score:2)
If it's so easy and healthy to use C++ in the kernel, that means it should be easy to fork.
Let's see how it pans out in practice.
Achieving what? What on earth makes you think anyone anywhere has an appetite for a fork in the kernel? What makes you think the best path forward is to provide programmers not the option of C++ for functionality, but the effective requirement to implement the same code in 2 languages if they want to cover all of the new forked linux world?
Forks are not a panacea, in fact they are as much of a problem as they are a solution.
Re: (Score:2)
A good fork takes over the initial purpose of the project. See: egcs fork.
Forking isn't bad if there is actual difference of opinion on direction of a project. If there is critical mass for a change like C++, this is a no-brainer, it will just happen. Otherwise it's a minority viewpoint trying to get its way, which won't happen unless the minority is more active codewise. Hence the reason for forking. The more energetic fork will win.
Not Converting But Adding (Score:3, Insightful)
If everyone could please understand just what is being proposed, it would make the conversation better. They are simply talking about adding the ability to use C++ in the kernel versus actually replacing all the code....big difference. Basically it is the same as the Rust addition where new items can be written in Rust.
Re: (Score:2)
It's even less than the Rust addition, since they aren't adding a new compiler to the toolchain.
I have used C++ since 1996 (Score:2)
Re: I have used C++ since 1996 (Score:2)
It works (Score:2)
Leave it the fuck alone.
Re: (Score:2)
Eh?
You do realise that no one is leaving the kernel alone. It's undergoing pretty rapid development with a new point release roughly ever two months. If you want it "left alone", you can just take a snapshot and never update.
Re: (Score:2)
Leave it the fuck alone.
It doesn't work. People can't add C++ to the kernel. Making a small change with a handful of minor patches fixes this.
Who can remember... (Score:2)
Re: (Score:2)
> Choice: copy-paste the encryption code, doubling maintenance or instantiate a web server object where it makes no sense.
make it a static member function? That's as bad as a C encryption function that takes a struct http_server * as first argument because reasons...
Also now (since c++11) you get to put functions into a namespace.
> I think modern C++ may have parametric polymorphism too
Yes: templates. All versions of C++ have that.
> Using C++ seems OK for a module
Please don't use the term "module"
Re: (Score:2)
The thing I hate about C++ is the way functions get "locked up" in classes. Let's say you've got a network server that implements an encryption function. Great. It needs that. No problem. Then you've got some other code that needs that function, but it's totally not a web server. Choice: copy-paste the encryption code, doubling maintenance or instantiate a web server object where it makes no sense.
What would you do in C? Well, probably what you'd do is expose it via the header file and if you were feeling l
Re: (Score:2)
Apparently not many people think your ill-founded opinion is the truth. Deal with it.