Scope-based resource management for the kernel
Scope-based resource management for the kernel
Posted Jun 22, 2023 9:24 UTC (Thu) by make (subscriber, #62794)In reply to: Scope-based resource management for the kernel by marcH
Parent article: Scope-based resource management for the kernel
If that's your main issue, then luckily it's a non-issue.
The premise of the article is that the kernel developers have already decided they want (something like) RAII, and my point is that for this feature, C++ is a better tool than C with non-standard extensions.
Discussions which C++ features are allowed in the kernel is no different than any other coding style discussion. There are already discussions on which C standard shall be used and which new C standard features are acceptable in the kernel (like atomics). Nothing new here, just more of the usual.
> Another top problem is: "C++ is not hard, your developers are just holding it wrong".
That's a straw man. Let's discuss the language rather than discussing theoretical arguments from hypothetical C++ fanboys, because that's not relevant for the language choice.
About C++: I know very well that C++ is hard, and I admit it's a complex mess of a language. Many reasonable things can be said about the ugliness of C++.
If you're starting with C, and you want to use certain advanced features like RAII, C++ is a good choice, because the migration is so simple. It is certainly reasonable to say Rust is better than C++, and I don't argue C++ should be used *instead* of Rust - I only say C++ could easily be used *now* to improve code quality where a Rust migration is not possible currently. Additionally, a future rewrite to Rust is easier from C++ with RAII than from plain C, because the source code flow in C++ and Rust is similar. C++ is actually a good intermediate language for a smoother migration to Rust.
Posted Jun 22, 2023 10:32 UTC (Thu)
by mb (subscriber, #50428)
[Link] (8 responses)
No, not at all.
It does not work to say that we're going to switch to C++ but only use RAII from it.
It's better to keep that huge amount of stuff out of the kernel to begin with.
Posted Jun 22, 2023 18:38 UTC (Thu)
by make (subscriber, #62794)
[Link] (7 responses)
You're missing the point. The article and this thread is about using RAII in the Linux kernel, not about inheritance. RAII works the same in C++ and Rust (and in C with GNU extensions, as it's going to be used soon).
The fact that C++ has features that Rust has not (which I didn't suggest to use and which do not affect the code flow) does not falsify my argument - it doesn't even have anything to do with this thread.
> It does not work to say that we're going to switch to C++ but only use RAII from it.
It works with other C language features or Rust language features or coding style policies or anything else. What makes you think policies about acceptable C++ features are different? Just because of "arguing over and over again"? Why is arguing over C++ features different? Bikeshedding discussions have existed as long as Linux exists, and will always exist. This argument seems rather arbitrary, because you can use the same argument to reject C11, C17, Rust (or anything else).
> The C implementation might not be as pretty as C++
Agree. We don't agree on the rest, but that's fine.
Posted Jun 22, 2023 18:55 UTC (Thu)
by mb (subscriber, #50428)
[Link] (6 responses)
No. But you didn't read my full text, before answering on the first paragraph.
>What makes you think policies about acceptable C++ features are different?
So you really think that inheritance and virtual functions would not be one of the first next C++ features that people would demand, if we would compile the kernel with a C++ compiler?
Converting all manual implementations of virtual function calls is the next obvious transistion we would have.
Posted Jun 22, 2023 19:07 UTC (Thu)
by make (subscriber, #62794)
[Link] (3 responses)
Oh yes, you were missing the point, because instead of replying to the point I made (about RAII), you made up a new story and replied to this story of yours.
Now you came up with a new story, this time about virtual functions, only to prove that code flow in C++ and Rust is different after all, but that again misses my point. Don't you get it? This article and this thread is about RAII and nothing else.
Posted Jun 22, 2023 19:19 UTC (Thu)
by mb (subscriber, #50428)
[Link] (2 responses)
Nice that you agree.
Posted Jun 22, 2023 19:35 UTC (Thu)
by make (subscriber, #62794)
[Link] (1 responses)
No, I don't agree. Virtual functions don't affect the code flow; they are just syntactic sugar for dynamic dispatch, but the code flow is the same as with other ways of doing dynamic dispatch (no matter if C++, C or Rust). But, uh, we're now even more off-topic, you're dragging me away from the topic (=RAII) so much, that I'm confident you're just a troll, and I've already been feeding you too much, shame on me. That was unexpected on LWN.
Posted Jun 22, 2023 19:41 UTC (Thu)
by mb (subscriber, #50428)
[Link]
No it isn't.
Posted Jun 22, 2023 20:51 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (1 responses)
Of course it would; implementing classes in C is not fun at all and it's done all over the kernel already: https://lwn.net/Articles/444910/
BTW I suspect this is another reason people want to keep C++ out: Object-Oriented Obfuscation. There are some problems to which object-orientation maps well but C++ went really "all-in" and kept functional programming techniques out of developers' mindsets for much too long of a time, holding back the entire industry for decades.
Funny how Javascript out of all languages helped functional programming finally break out.
Rust is of course more functional than OO.
Posted Jun 22, 2023 21:02 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Forgot the mandatory reference to the masterpiece, sorry for the extra email:
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
Yes this one is not about C++ but Java which is even worse. But: close enough.
Posted Jun 22, 2023 20:42 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Not "mine"; the issue of everyone who does not want C++
> then luckily it's a non-issue.
Must feel good to be right when so many people are wrong :-)
> my point is that for this feature, C++ is a better tool than C with non-standard extensions.
Yes! But: see above.
> Discussions which C++ features are allowed in the kernel is no different than any other coding style discussion.
Qualitatively yes. Quantitatively no. I know: I don't have any metrics to show you; these things are very hard to measure. But you don't have any either and the consensus / educated guess in Linux (and some other projects) is that the trade-off is not worth it. That is of course based on observations in other, actual C++ projects, I mean the lack of metrics does not mean it's based on thin air either.
BTW: which features are allowed is IMHO a small part of code style discussions. A very important part of course, maybe the most important one but small in "email volume". I'm just saying "code style" is not a great choice of words here, never mind.
> That's a straw man. Let's discuss the language rather than discussing theoretical arguments from hypothetical C++ fanboys
Oh come on: "you're holding it wrong" is the typical answer of _every_, _real_ C++ fanboy! Very vocal and hopefully not representative as usual on the Internet but certainly not "hypothetical".
> I know very well that C++ is hard, and I admit it's a complex mess of a language.
Thank you!
Scope-based resource management for the kernel
Rust has no inheritance. Code flows between ideomatic C++ and ideomatic Rust are quite different.
People *will* start using more and more of C++'s features.
The C implementation might not be as pretty as C++, but pulling in C++ comes with a tremendous cost of arguing over and over again why this and that C++ feature shall not be used in the kernel.
Scope-based resource management for the kernel
Scope-based resource management for the kernel
And there goes your same code flow.
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel