4 ms·

Your getting downvoted, but you are kind-of correct. Even if it isn't actually written in C++, there is a lot of "OO-style" code in the kernel that does things

Your getting downvoted, but you are kind-of correct. Even if it isn't actually written in C++, there is a lot of "OO-style" code in the kernel that does things like dynamic disoatch using VTables...basically making explicit what C++ is going to do behind the scenes for you anyways. I can see the argument from Linus' POV about avoiding over abstraction, and knowing exactly what your code is doing on a low-level, but at the same time it leads to a lot of reinventing the wheel and makes me think there is a better balance to be found. https://lwn.net/Articles/444910/ https://lwn.net/Articles/444910/ https://lwn.net/Articles/446317/ https://lwn.net/Articles/446317/

madez 9y ago
It doesn't only make you think there is a better balance, it also makes you think harder whether the task at hand needs this kind of complexity. If this is all hidden under abstraction, developers might not care enough.
- TFortunato 9y ago
  I absolutely agree with you on the dangers of overabstracting / hiding too much detail. That said, I do wonder if things have changed, since Linus's c++ "rant" re: the type of developers who would choose to work on kernel code in c++. I do remember a time when learning c++ was very much in popular, before the "in" language moved to java, to python, to JS, etc., so there may have been more of a problem with inexperienced coders back then than there is now. (I have no idea if this is true at all, just curious!) I'm addressing this as someone who has done C++ work on very small embedded systems (e.g. microcontrollers with no external memory) including RTOS code and low-latency control loops, and there were definitely some nice features in C++ that can save you some time and lines of code without adding a bunch of needless overhead. Of course, there was a learning curve when bringing new people on board the project about what was/wasn't allowed for performance reasons. In general though, I see no reason why there couldn't be some subset of C++ used for kernel development other than Linus' / the kernel dev community's general distaste for it.

madez 9y ago

It doesn't only make you think there is a better balance, it also makes you think harder whether the task at hand needs this kind of complexity. If this is all hidden under abstraction, developers might not care enough.

TFortunato 9y ago
I absolutely agree with you on the dangers of overabstracting / hiding too much detail. That said, I do wonder if things have changed, since Linus's c++ "rant" re: the type of developers who would choose to work on kernel code in c++. I do remember a time when learning c++ was very much in popular, before the "in" language moved to java, to python, to JS, etc., so there may have been more of a problem with inexperienced coders back then than there is now. (I have no idea if this is true at all, just curious!) I'm addressing this as someone who has done C++ work on very small embedded systems (e.g. microcontrollers with no external memory) including RTOS code and low-latency control loops, and there were definitely some nice features in C++ that can save you some time and lines of code without adding a bunch of needless overhead. Of course, there was a learning curve when bringing new people on board the project about what was/wasn't allowed for performance reasons. In general though, I see no reason why there couldn't be some subset of C++ used for kernel development other than Linus' / the kernel dev community's general distaste for it.