3 ms·

What C++ features have you missed when working on the kernel?

jcelerier 5y ago
This thread is literally about something that is a solved problem since 1991 in c++ (generic lists and data structures) and apparently still an issue in the kernel in 2022
- throwawaylinux 5y ago
  This did not answer my question.
  - jcelerier 5y ago
    Is "ability to write reusable generic containers" not an answer ?
    - throwawaylinux 5y ago
      No, because Linux has generic lists and data structures so you'd have to be more specific. Also I was asking a particular person to because their perspective would have been interesting to me, but if you're also a kernel developer I would be interested to hear your gripes too.
- cameryn7 5y ago
  Intrusive lists in C++ is not particularly more convenient over C (especially not in 1991's C++)
  - pjmlp 5y ago
    Borland C++ 3.0 for MS-DOS supported templates in 1991. https://winworldpc.com/product/borland-c/30 https://winworldpc.com/product/borland-c/30
    - tialaramex 5y ago
      And likewise Mozilla M-series builds supported DOM mangling 20+ years ago. On paper that sounds like you could do much of what we do today, maybe with a little more effort but it'd work, right? Nope. In those M-series builds DOM mangling routinely crashed the browser. "Ask me how I know". And likewise your Borland C++ 3.0 "support" for templates means a lot of basic stuff works but if you try to get fancy (and of course there's no guidance provided on what's "fancy") you will get spurious errors or blow up the compiler, or worst of all, silently produce wrong binaries... More than that though, having templates doesn't magically fix this problem. jcelerier says C++ fixes it by offering "generic lists" in 1991. But... it doesn't. In 1993-4 Stepanov presents the STL to the committee, with what will become std::list but that's not an intrusive list. So you would need to do all the heavy lifting to build your own intrusive lists, they are not, in fact, supplied with the language. Thus we'd be in the exact same place, with people arguing about the implementation, except that (from experience) C++ proponents would be saying what the kernel needs is yet more C++ features...
      - pjmlp 5y ago
        You mean the same Mozilla that has killed Servo, layed off most Rust devs, keeps using C++ for the remaing part of Firefox, while trying to avoid fading into irrelevance, while Chrome and WebKit show no signs to ever move beyond C++, in spite of some exploratory work with Rust? Or Rust existence depending on LLVM and GCC, both C++ projects, that will never adopt Rust as their main development language? Better take care with the code generated by those C++ projects landing into the kernel as part of Rust runtime/stdlib.
        tialaramex 5y ago
        Well in this case I'm talking about Mozilla the web browser, the initial product of Mozilla, years before Firefox. But yes, that's the right organisation. Never is a very long time. Maybe safer to say they have no immediate intentions. What is with the weird Nazi purity thinking when it comes to "code generated by those C++ projects" ? You know Linux is built with GCC today right? Also - as I am pretty sure I explained to you before - Rust's standard libraries are arranged in a stack, the Rust for Linux project uses the ordinary core library (which implements a variety of useful stuff including core::iter::Iterator and core::option::Option) and provides its own alloc (a library for the allocator and the features that depend on it, such as alloc::boxed::Box but with explicit allocation and Error returns) however the rest of std is not supplied, Rust for Linux does supply kernel, which is full of kernel-specific stuff like kernel::random::getrandom This is a much clearer division than is provided in the C++ Standard Library.

This thread is literally about something that is a solved problem since 1991 in c++ (generic lists and data structures) and apparently still an issue in the kernel in 2022

throwawaylinux 5y ago
This did not answer my question.
- jcelerier 5y ago
  Is "ability to write reusable generic containers" not an answer ?
  - throwawaylinux 5y ago
    No, because Linux has generic lists and data structures so you'd have to be more specific. Also I was asking a particular person to because their perspective would have been interesting to me, but if you're also a kernel developer I would be interested to hear your gripes too.
cameryn7 5y ago
Intrusive lists in C++ is not particularly more convenient over C (especially not in 1991's C++)
- pjmlp 5y ago
  Borland C++ 3.0 for MS-DOS supported templates in 1991. https://winworldpc.com/product/borland-c/30 https://winworldpc.com/product/borland-c/30
  - tialaramex 5y ago
    And likewise Mozilla M-series builds supported DOM mangling 20+ years ago. On paper that sounds like you could do much of what we do today, maybe with a little more effort but it'd work, right? Nope. In those M-series builds DOM mangling routinely crashed the browser. "Ask me how I know". And likewise your Borland C++ 3.0 "support" for templates means a lot of basic stuff works but if you try to get fancy (and of course there's no guidance provided on what's "fancy") you will get spurious errors or blow up the compiler, or worst of all, silently produce wrong binaries... More than that though, having templates doesn't magically fix this problem. jcelerier says C++ fixes it by offering "generic lists" in 1991. But... it doesn't. In 1993-4 Stepanov presents the STL to the committee, with what will become std::list but that's not an intrusive list. So you would need to do all the heavy lifting to build your own intrusive lists, they are not, in fact, supplied with the language. Thus we'd be in the exact same place, with people arguing about the implementation, except that (from experience) C++ proponents would be saying what the kernel needs is yet more C++ features...
    - pjmlp 5y ago
      You mean the same Mozilla that has killed Servo, layed off most Rust devs, keeps using C++ for the remaing part of Firefox, while trying to avoid fading into irrelevance, while Chrome and WebKit show no signs to ever move beyond C++, in spite of some exploratory work with Rust? Or Rust existence depending on LLVM and GCC, both C++ projects, that will never adopt Rust as their main development language? Better take care with the code generated by those C++ projects landing into the kernel as part of Rust runtime/stdlib.
      - tialaramex 5y ago
        Well in this case I'm talking about Mozilla the web browser, the initial product of Mozilla, years before Firefox. But yes, that's the right organisation. Never is a very long time. Maybe safer to say they have no immediate intentions. What is with the weird Nazi purity thinking when it comes to "code generated by those C++ projects" ? You know Linux is built with GCC today right? Also - as I am pretty sure I explained to you before - Rust's standard libraries are arranged in a stack, the Rust for Linux project uses the ordinary core library (which implements a variety of useful stuff including core::iter::Iterator and core::option::Option) and provides its own alloc (a library for the allocator and the features that depend on it, such as alloc::boxed::Box but with explicit allocation and Error returns) however the rest of std is not supplied, Rust for Linux does supply kernel, which is full of kernel-specific stuff like kernel::random::getrandom This is a much clearer division than is provided in the C++ Standard Library.