These are all standard C and C++ interop problems also found in userland and typically go away if the C project at hand is cooperative.
C++ in the Linux Kernel
31–40 of 102 posts
Re: C++ in the Linux Kernel
#32Re: C++ in the Linux Kernel
#33Lol, part of me likes the effort taken just because, but the kernel devs _really_ do not want C++. One hint: "struct class" https://elixir.bootlin.com/linux/latest/source/include/linux...
What bothers me about that is that, because C doesn't have namespaces, it's already a terrible name for a struct. What if you want another "class" of thing?
Call it device_class ffs
Re: C++ in the Linux Kernel
#34Earlier quoted context omitted.
AVRs don't have enough storage for templated code to explode into an unmanageable problem.
Somehow C64 can deal with them. "CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”" https://www.youtube.com/watch?v=zBkNBP00wJE "C++20 For The Commodore 64" https://www.youtube.com/watch?v=EIKAqcLxtT0
But a C64 is still only talking about 64kB of RAM. The post you're replying to claims that Template complexity gets unreasonable on a large machine, such as a Linux system. Not sure I agree, but "it's fine on a C64" isn't evidence in your favour unless you've forgotten Linux doesn't even run on a Commodore 64.
Re: C++ in the Linux Kernel
#35In the past, I wrote a unix like kernel from scratch in C++. I have summarized what I had to do to get C++ code run on bare metal in this article https://www.avabodh.com/cxxin/nostdlib.html
I've always been interested in writing my own Unix-like kernel! Could you share what resources you used to write it? How long did the whole thing take?
Just to understand the scope of the work, did you implement any of the following: memory isolation, networking, concurrency via interleaving on single thread, parallelism where n threads can run n processes simultaneously? How long did each take to get done?
Re: C++ in the Linux Kernel
#36Lol, part of me likes the effort taken just because, but the kernel devs _really_ do not want C++. One hint: "struct class" https://elixir.bootlin.com/linux/latest/source/include/linux...
What bothers me about that is that, because C doesn't have namespaces, it's already a terrible name for a struct. What if you want another "class" of thing? Call it device_class ffs
[deleted]
Re: C++ in the Linux Kernel
#37I guess Rust is far better choise for that.
Community wise, yes. It seems to have gained some momentum. From a technical point of view, I'm not so sure. C++ still interoperate easier with C than Rust, if only because you can normally just include the headers and be done with it. (Although as the article says, there are some cleanup to do.)
From an everything point of view, there's no point in adding complexity for no tangible benefit. Rust has tangible benefits (memory safety). Very far from a silver bullet, but demonstrably better than C.
Rust isn't being experimented with in the kernel because someone decided we should really add a second language. C++ interop with C doesn't matter when there's no reason to use C++ in the kernel anyway.
Re: C++ in the Linux Kernel
#38Earlier quoted context omitted.
Somehow C64 can deal with them. "CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”" https://www.youtube.com/watch?v=zBkNBP00wJE "C++20 For The Commodore 64" https://www.youtube.com/watch?v=EIKAqcLxtT0
But a C64 is still only talking about 64kB of RAM. The post you're replying to claims that Template complexity gets unreasonable on a large machine, such as a Linux system. Not sure I agree, but "it's fine on a C64" isn't evidence in your favour unless you've forgotten Linux doesn't even run on a Commodore 64.
So it is fine on a 64KB system, but unmanageable on a platform that gets all the different kinds of boilerplate to run cloud workloads, got it
Re: C++ in the Linux Kernel
#39I guess Rust is far better choise for that.
Community wise, yes. It seems to have gained some momentum. From a technical point of view, I'm not so sure. C++ still interoperate easier with C than Rust, if only because you can normally just include the headers and be done with it. (Although as the article says, there are some cleanup to do.)
The "interoperate easier" idea is a trap for both C and C++ and worth avoiding because in fact they aren't quite compatible, so you're making both languages worse to achieve this. I don't much like C++, but if you must use C++, actually use C++ and forget that it's sorta kinda "compatible" with C.
Re: C++ in the Linux Kernel
#40I guess Rust is far better choise for that.
There is no reason that Rust doesn't share the same infrastructure problems. The main difference is that the kernel maintainers want Rust in the kernel, while if you want to maintain a module written in C++ then you are on your own.