13 ms·

There are plenty of operating systems that use C++ on the kernel side of things. Some things, like exceptions, are frowned upon and rarely used -- if at all --

by alxlaz 9y ago

There are plenty of operating systems that use C++ on the kernel side of things. Some things, like exceptions, are frowned upon and rarely used -- if at all -- but there is no shortage of C++ kernel code. Just not in Linux. When it comes to Linux, one could say that most reasons to avoid it are historical, but this does not quite paint the awkward truth -- namely that, for most of the kernel's lifetime (since back in 1991), C++ compilers simply did not have the level of maturity and stability across the breadth of platforms that Linux required. Linus Torvalds' stance on this matter is pretty well-known: http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus . Today, when x86-64 and ARM are the only two families that you need to care about in the following ten years or so (maybe RISC-V but I rather doubt it), it probably makes sense to look at C++ for operating systems work, but the runtime is certainly heavier than back when Linus was writing about it, too. A modern C++ compiler has a lot of baggage; C++ was huge back in 1998, now it's bloody massive. IMHO, all the reasons why you would want to use C++ (templating support without resorting to strange hacks, useful pointer semantics and so on) are reasonably well-served by cleaner languages with less hefty runtimes, like Rust. What these alternatives do lack is the amazing level of commercial support that C++ has.

jcelerier 9y ago
> C++ was huge back in 1998, now it's bloody massive. I don't think any "run-time" feature was added since, though. It's all either OS support (<thread>, etc, that you wouldn't use in-kernel anyways) or template stuff that has 0 impact on runtime (and actually sometimes helps decreasing code size). https://istarc.wordpress.com/2014/07/18/stm32f4-oop-with-embedded-systems/ https://istarc.wordpress.com/2014/07/18/stm32f4-oop-with-emb... https://www.embedded.com/design/programming-languages-and-tools/4438660/Modern-C--in-embedded-systems---Part-1--Myth-and-Reality https://www.embedded.com/design/programming-languages-and-to... https://hackaday.com/2015/12/18/code-craft-embedding-c-templates/ https://hackaday.com/2015/12/18/code-craft-embedding-c-templ... If some guys are able to run c++ on 8kb microcontrollers, there's hardly a non-political reason it couldn't be used in-kernel. See also IncludeOS: http://www.includeos.org/ http://www.includeos.org/
- alxlaz 9y ago
  Additions have certainly been made since back in 1998 (things like smart pointers are relatively new on this scale, as far as I know). Many runtimes for resource-constrained embedded systems do not support all of C++'s features. Exceptions are the most usual omission. You can certainly strip things down to a subset that can fit 128K of flash and need only 1 or 2K of RAM at runtime, but the question is not only one of computational resources used for the library itself. Additional code always means additional bugs, the semantics sometimes "hide" memory copying or dynamic allocation in ways that many C++ programmers do not understand (and the ones who do are more expensive to hire than the ones who do not), and so on. You can certainly avoid these things and use C++, but you can also avoid them by using C. I agree that mistrust and politics definitely play the dominating role in this affair though. I have seen good, solid, well-performing C++ code. I prefer C, but largely due to a vicious circle effect -- C is the more common choice, so I wrote more C code, so I know C better, so unless I have a good reason to recommend or write C++ instead of C, I will recommend or write C instead. I do think (possibly for the same reason) that it is harder to write correct C++ code than it is to write correct C code, but people have sent things to the Moon and back using assembly language for very weird machines, so clearly there are valid trade-offs that can be made and which include using language far quirkier than C++.
  - cmrdporcupine 9y ago
    I absolutely do not understand your point. Anybody doing OS development in C++ is doing so with absolutely no C++ standard library support, same as if you were using C++ to develop for your microcontroller. If C++ binaries are compact enough for Arduino or Parallax Propeller development (<32KB RAM), they are absolutely fine for kernel development. The real answer is historical, and cultural. On the latter, Unix is a product of C (well, and BCPL) and C is a product of Unix. They two are intertwined heavily. The former is as was mentioned a product of the relative crappiness of early C++ compilers (and the overzealous OO gung-ho nature of its early adopters perhaps as well...) C++ without exceptions, RTTI, etc. has a lot to offer for OS development. Working within the right constraints it can definitely make a lot of tasks easier and cleaner. It won't happen in Linux, tho.
ahoka 9y ago
> There are plenty of operating systems that use C++ on the kernel side of things. Some things, like exceptions, are frowned upon and rarely used -- if at all -- but there is no shortage of C++ kernel code. Just not in Linux. I used to work on one. It was developed in the 90s, around the same time C++ became an ISO standard. I think most of you have used it without knowing. :) I think OOP is natural for writing kernels and most mainstream kernels implement some kind of object system because of this. I also wrote my toy kernel in modern C++, despite that I'm "fluent" in both C and C++. So yeah, C++ kernels are here, just not in Linux land.
- saagarjha 9y ago
  Are you referring to macOS?
  - Cyph0n 9y ago
    I think the kernel itself is called Mach. Not sure if it was written in C++ though.
    - sigjuice 9y ago
      The kernel is called XNU. https://opensource.apple.com/source/xnu/ https://opensource.apple.com/source/xnu/ It is mainly written in C.
      - self_awareness 9y ago
        The BSD part of the kernel is written in C, but IOKit, the kext framework, is written in (a subset of) C++: http://xr.anadoxin.org/source/xref/macos-10.13-highsierra/xnu-4570.1.46/iokit/Kernel/ http://xr.anadoxin.org/source/xref/macos-10.13-highsierra/xn...
  - ahoka 9y ago
    Nah. Something from telco land.
nabla9 9y ago
>Today, when x86-64 and ARM are the only two families that you need to care about Wait what? What happened to MIPS, z/Architecture,Power Architecture, QDSP6, TMS320?
- alxlaz 9y ago
  I meant that strictly in the realm of general-purpose operating systems (the article is, after all, about writing a Linux kernel). Two of those are DSPs. The Linux kernel and busybox account for 99,99% of the general-purpose code running on them, and bare-metal code for both is still very common. In fact, Linux runs on QDSP6 only under a hypervisor, and gained C6x support only somewhat recently (~5 years, I think?). Last time I saw a MIPS workstation was a very long time ago :-) and, barring a few niche efforts, the same goes for PowerPC as well. Back when Linus was ranting, one could make a convincing case for supporting all of these architectures in an OS meant for general-purpose workloads, from server to desktop and from thin client (eh? feel old yet :-)?) to VCR -- and . Now you can sell an OS that supports nothing but x86-64 and a few ARMs, and you get most of the server market, and virtually all of the desktop and mobile market. Obviously the architectures that you need for a particular project are the ones that you want to "care for" -- but in broad terms, it is perfectly possible today for someone to have worked as a programmers for ten years without encountering a single machine that is not either x86 or ARM-based. Someone who had 10 years of programming experience in 2003 probably ran into a SPARC system whether they wanted or not.
  - johncolanduoni 9y ago
    I think you’ve missed large segments of Linux’s user base; you’ve definitely missed Android devices using MIPS processors.
    - PeCaN 9y ago
      Or even more commonly, MIPS routers using Linux.
    - BlackLotus89 9y ago
      Name one recent android device using mips. There are, to my knowledge, only a handful of mips android devices (literally). There was an announcement for a 64bit mips android device for 2016 (Warrior i6400) but I didn't hear anything about it. Did you? Also there was an ainol tablet with the mips architecture (nov07) which flopped (those are the only instances I can recall where mips on android really came into play).
jlg23 9y ago
I don't get how you make the connection from Torvald's arguments to what you say. His complaints are on a fundamentally different level: ~"Programmers over-abstracting are a timeless problem, the more complex the language/standard library, the easier it is for programmers to get lost in abstraction. Bad programmers just get lost, mediocre programmers even defend what they do." I despise his choice of words and general attitude towards programmers "less capable than him", but I do think there is some truth in what he says there: Imagine we'd all be writing asm only - we'd spend much more time on the drawing board and find much more elegant solutions to problems that we today solve with mindlessly writing hundreds lines of code within a "framework". Side note: I wrote C++ in 1998; it was more "bloody massive" back then than it is today, in my humble experience.
- alxlaz 9y ago
  I was referring only to the parts of that rant that are/were of some objective value, e.g.: > anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny > the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. You can certainly write C++ code without overabstracting it. Maybe Torvalds only ran into C++ programmers who liked overabstracting their code -- as it is usually the case with opinions of some people about other people, that part of the rant is best discarded :-). But as my memory serves me, back when "portability" meant x86, SPARC, Alpha, ARM, MIPS, PPC, PA-RISC and m68k, the only way to do "good, efficient, and system-level and portable C++" was to limit yourself to the (relatively small) subset of C++ that was well-implemented by widely-available compilers (particularly GCC) across all these architectures -- not as a matter of discipline and code elegance, but because writing non-trivial C++ code back then usually resulted in very unpleasant trips down the standard library's source code and poring over objdump outputs trying to figure out what the hell broke this time.
  - pjmlp 9y ago
    Yeah, which is why Java felt like fresh air compared with those portability hurdles.
vkjv 9y ago
Has Linux stated any opinions on rust? Some of his issues with C++ also apply to rust. > any compiler or language that likes to hide things like memory
- steveklabnik 9y ago
  “That's not a new phenomenon at all. We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters.” https://www.infoworld.com/article/3109150/linux/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html https://www.infoworld.com/article/3109150/linux/linux-at-25-...
  - madez 9y ago
    Is Rust available on the platforms Linux targets? The kernel community won't react fondly to tries to restrict the target support. I'd expect a justified rant with lots of insults at intellect and sanity, if need be. Is Rust well-understood, both by the users and the toolchain developers? How many independent compilers are there for Rust? What architectures do they support? I'm not implying that Rust isn't suitable for Linux, but it has open issues, that prevent usage right now. Rust and it's core ecosystem have a lot of churn, and still feel like a rather early work-in-progress. One example not mentioned is the Rust language server and its integration with consumers. I cheer for Rust, and hope for solid progress.
    - flukus 9y ago
      Another issue I've seen with rust (benchmarks) that's rarely talked about is memory usage, which is pretty important in a kernel. Sometime it only uses a little more memory, but quite often it will use twice as much and occasionally an order of magnitude more. To be fair these benchmarks are aiming for speed, but the c baseline typically produces faster code with less memory, so it may very well be a case of TANSTAAFL.
      - madez 9y ago
        I don't see how it necessarily must be TANSTAAFL. Maybe Rust is indeed suited for being zero-cost in memory and speed performance compared to C, but the toolchain isn't there yet.
comex 9y ago
I’m not sure the number of hardware architectures matters that much, as opposed to the number of OSes or compilers. If you have to target N different C++ compilers written independently by different vendors, then sure, each compiler has a heck of a lot of room for bugs in the frontend or standard library. But with a given compiler (say, GCC or Clang) that has N architecture backends, there shouldn’t be that much added risk of architecture-dependent bugs with C++, compared to pure C. After all, most of the “extra stuff” that C++ adds on to C has no inherent hardware dependence and exists only on the frontend. By the time the code makes its way to the backend, templates have been monomorphized (i.e. copied and pasted for each set of parameters); methods have been lowered to functions with added ‘this’ parameters; hidden calls to destructors and conversions have been made explicit; and so on. For any given C++ program, you could write a C program that compiles to near-identical IR, so if the backend can reliably compile C code, it should be able to handle C++. True, that hypothetical C program might not look much like a typical human-written program. In order to achieve zero-cost abstractions, C++ code tends to rely a lot more on inlining and other backend optimizations than pure C, even though those optimizations apply to both languages. So if the backend isn’t reliable, C++ may generate more ‘weird’ IR that could end up getting miscompiled, and the level of indirection may make it harder to figure out what’s going on. But compiler backends these days are a lot more reliable than they used to be. And buggy backends can certainly cause problems for C code as well.
lloeki 9y ago
> There are plenty of operating systems that use C++ on the kernel side of things Language-wise, Darwin/XNU/IOkit uses a subset of C++, notably one that excludes exceptions and templates IIRC. stdlib-wise I suspect it's even more restricted/different.
pjmlp 9y ago
BeOS, Symbian, macOS, Windows, AS/400, GenodeOS, mbedOS Just a couple of examples.
- waddlesplash 9y ago
  BeOS' kernel itself didn't use C++ if I recall correctly, though some drivers did. Haiku, BeOS' open-source successor, has a kernel written almost entirely in C++.

by alxlaz 9y ago

jcelerier 9y ago

> C++ was huge back in 1998, now it's bloody massive. I don't think any "run-time" feature was added since, though. It's all either OS support (<thread>, etc, that you wouldn't use in-kernel anyways) or template stuff that has 0 impact on runtime (and actually sometimes helps decreasing code size). https://istarc.wordpress.com/2014/07/18/stm32f4-oop-with-embedded-systems/ https://istarc.wordpress.com/2014/07/18/stm32f4-oop-with-emb... https://www.embedded.com/design/programming-languages-and-tools/4438660/Modern-C--in-embedded-systems---Part-1--Myth-and-Reality https://www.embedded.com/design/programming-languages-and-to... https://hackaday.com/2015/12/18/code-craft-embedding-c-templates/ https://hackaday.com/2015/12/18/code-craft-embedding-c-templ... If some guys are able to run c++ on 8kb microcontrollers, there's hardly a non-political reason it couldn't be used in-kernel. See also IncludeOS: http://www.includeos.org/ http://www.includeos.org/

alxlaz 9y ago
Additions have certainly been made since back in 1998 (things like smart pointers are relatively new on this scale, as far as I know). Many runtimes for resource-constrained embedded systems do not support all of C++'s features. Exceptions are the most usual omission. You can certainly strip things down to a subset that can fit 128K of flash and need only 1 or 2K of RAM at runtime, but the question is not only one of computational resources used for the library itself. Additional code always means additional bugs, the semantics sometimes "hide" memory copying or dynamic allocation in ways that many C++ programmers do not understand (and the ones who do are more expensive to hire than the ones who do not), and so on. You can certainly avoid these things and use C++, but you can also avoid them by using C. I agree that mistrust and politics definitely play the dominating role in this affair though. I have seen good, solid, well-performing C++ code. I prefer C, but largely due to a vicious circle effect -- C is the more common choice, so I wrote more C code, so I know C better, so unless I have a good reason to recommend or write C++ instead of C, I will recommend or write C instead. I do think (possibly for the same reason) that it is harder to write correct C++ code than it is to write correct C code, but people have sent things to the Moon and back using assembly language for very weird machines, so clearly there are valid trade-offs that can be made and which include using language far quirkier than C++.
- cmrdporcupine 9y ago
  I absolutely do not understand your point. Anybody doing OS development in C++ is doing so with absolutely no C++ standard library support, same as if you were using C++ to develop for your microcontroller. If C++ binaries are compact enough for Arduino or Parallax Propeller development (<32KB RAM), they are absolutely fine for kernel development. The real answer is historical, and cultural. On the latter, Unix is a product of C (well, and BCPL) and C is a product of Unix. They two are intertwined heavily. The former is as was mentioned a product of the relative crappiness of early C++ compilers (and the overzealous OO gung-ho nature of its early adopters perhaps as well...) C++ without exceptions, RTTI, etc. has a lot to offer for OS development. Working within the right constraints it can definitely make a lot of tasks easier and cleaner. It won't happen in Linux, tho.

ahoka 9y ago

> There are plenty of operating systems that use C++ on the kernel side of things. Some things, like exceptions, are frowned upon and rarely used -- if at all -- but there is no shortage of C++ kernel code. Just not in Linux. I used to work on one. It was developed in the 90s, around the same time C++ became an ISO standard. I think most of you have used it without knowing. :) I think OOP is natural for writing kernels and most mainstream kernels implement some kind of object system because of this. I also wrote my toy kernel in modern C++, despite that I'm "fluent" in both C and C++. So yeah, C++ kernels are here, just not in Linux land.

saagarjha 9y ago
Are you referring to macOS?
- Cyph0n 9y ago
  I think the kernel itself is called Mach. Not sure if it was written in C++ though.
  - sigjuice 9y ago
    The kernel is called XNU. https://opensource.apple.com/source/xnu/ https://opensource.apple.com/source/xnu/ It is mainly written in C.
    - self_awareness 9y ago
      The BSD part of the kernel is written in C, but IOKit, the kext framework, is written in (a subset of) C++: http://xr.anadoxin.org/source/xref/macos-10.13-highsierra/xnu-4570.1.46/iokit/Kernel/ http://xr.anadoxin.org/source/xref/macos-10.13-highsierra/xn...
- ahoka 9y ago
  Nah. Something from telco land.

nabla9 9y ago

>Today, when x86-64 and ARM are the only two families that you need to care about Wait what? What happened to MIPS, z/Architecture,Power Architecture, QDSP6, TMS320?

alxlaz 9y ago
I meant that strictly in the realm of general-purpose operating systems (the article is, after all, about writing a Linux kernel). Two of those are DSPs. The Linux kernel and busybox account for 99,99% of the general-purpose code running on them, and bare-metal code for both is still very common. In fact, Linux runs on QDSP6 only under a hypervisor, and gained C6x support only somewhat recently (~5 years, I think?). Last time I saw a MIPS workstation was a very long time ago :-) and, barring a few niche efforts, the same goes for PowerPC as well. Back when Linus was ranting, one could make a convincing case for supporting all of these architectures in an OS meant for general-purpose workloads, from server to desktop and from thin client (eh? feel old yet :-)?) to VCR -- and . Now you can sell an OS that supports nothing but x86-64 and a few ARMs, and you get most of the server market, and virtually all of the desktop and mobile market. Obviously the architectures that you need for a particular project are the ones that you want to "care for" -- but in broad terms, it is perfectly possible today for someone to have worked as a programmers for ten years without encountering a single machine that is not either x86 or ARM-based. Someone who had 10 years of programming experience in 2003 probably ran into a SPARC system whether they wanted or not.
- johncolanduoni 9y ago
  I think you’ve missed large segments of Linux’s user base; you’ve definitely missed Android devices using MIPS processors.
  - PeCaN 9y ago
    Or even more commonly, MIPS routers using Linux.
  - BlackLotus89 9y ago
    Name one recent android device using mips. There are, to my knowledge, only a handful of mips android devices (literally). There was an announcement for a 64bit mips android device for 2016 (Warrior i6400) but I didn't hear anything about it. Did you? Also there was an ainol tablet with the mips architecture (nov07) which flopped (those are the only instances I can recall where mips on android really came into play).

jlg23 9y ago

I don't get how you make the connection from Torvald's arguments to what you say. His complaints are on a fundamentally different level: ~"Programmers over-abstracting are a timeless problem, the more complex the language/standard library, the easier it is for programmers to get lost in abstraction. Bad programmers just get lost, mediocre programmers even defend what they do." I despise his choice of words and general attitude towards programmers "less capable than him", but I do think there is some truth in what he says there: Imagine we'd all be writing asm only - we'd spend much more time on the drawing board and find much more elegant solutions to problems that we today solve with mindlessly writing hundreds lines of code within a "framework". Side note: I wrote C++ in 1998; it was more "bloody massive" back then than it is today, in my humble experience.

alxlaz 9y ago
I was referring only to the parts of that rant that are/were of some objective value, e.g.: > anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny > the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. You can certainly write C++ code without overabstracting it. Maybe Torvalds only ran into C++ programmers who liked overabstracting their code -- as it is usually the case with opinions of some people about other people, that part of the rant is best discarded :-). But as my memory serves me, back when "portability" meant x86, SPARC, Alpha, ARM, MIPS, PPC, PA-RISC and m68k, the only way to do "good, efficient, and system-level and portable C++" was to limit yourself to the (relatively small) subset of C++ that was well-implemented by widely-available compilers (particularly GCC) across all these architectures -- not as a matter of discipline and code elegance, but because writing non-trivial C++ code back then usually resulted in very unpleasant trips down the standard library's source code and poring over objdump outputs trying to figure out what the hell broke this time.
- pjmlp 9y ago
  Yeah, which is why Java felt like fresh air compared with those portability hurdles.

vkjv 9y ago

Has Linux stated any opinions on rust? Some of his issues with C++ also apply to rust. > any compiler or language that likes to hide things like memory

steveklabnik 9y ago
“That's not a new phenomenon at all. We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters.” https://www.infoworld.com/article/3109150/linux/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html https://www.infoworld.com/article/3109150/linux/linux-at-25-...
- madez 9y ago
  Is Rust available on the platforms Linux targets? The kernel community won't react fondly to tries to restrict the target support. I'd expect a justified rant with lots of insults at intellect and sanity, if need be. Is Rust well-understood, both by the users and the toolchain developers? How many independent compilers are there for Rust? What architectures do they support? I'm not implying that Rust isn't suitable for Linux, but it has open issues, that prevent usage right now. Rust and it's core ecosystem have a lot of churn, and still feel like a rather early work-in-progress. One example not mentioned is the Rust language server and its integration with consumers. I cheer for Rust, and hope for solid progress.
  - flukus 9y ago
    Another issue I've seen with rust (benchmarks) that's rarely talked about is memory usage, which is pretty important in a kernel. Sometime it only uses a little more memory, but quite often it will use twice as much and occasionally an order of magnitude more. To be fair these benchmarks are aiming for speed, but the c baseline typically produces faster code with less memory, so it may very well be a case of TANSTAAFL.
    - madez 9y ago
      I don't see how it necessarily must be TANSTAAFL. Maybe Rust is indeed suited for being zero-cost in memory and speed performance compared to C, but the toolchain isn't there yet.

comex 9y ago

I’m not sure the number of hardware architectures matters that much, as opposed to the number of OSes or compilers. If you have to target N different C++ compilers written independently by different vendors, then sure, each compiler has a heck of a lot of room for bugs in the frontend or standard library. But with a given compiler (say, GCC or Clang) that has N architecture backends, there shouldn’t be that much added risk of architecture-dependent bugs with C++, compared to pure C. After all, most of the “extra stuff” that C++ adds on to C has no inherent hardware dependence and exists only on the frontend. By the time the code makes its way to the backend, templates have been monomorphized (i.e. copied and pasted for each set of parameters); methods have been lowered to functions with added ‘this’ parameters; hidden calls to destructors and conversions have been made explicit; and so on. For any given C++ program, you could write a C program that compiles to near-identical IR, so if the backend can reliably compile C code, it should be able to handle C++. True, that hypothetical C program might not look much like a typical human-written program. In order to achieve zero-cost abstractions, C++ code tends to rely a lot more on inlining and other backend optimizations than pure C, even though those optimizations apply to both languages. So if the backend isn’t reliable, C++ may generate more ‘weird’ IR that could end up getting miscompiled, and the level of indirection may make it harder to figure out what’s going on. But compiler backends these days are a lot more reliable than they used to be. And buggy backends can certainly cause problems for C code as well.

lloeki 9y ago

> There are plenty of operating systems that use C++ on the kernel side of things Language-wise, Darwin/XNU/IOkit uses a subset of C++, notably one that excludes exceptions and templates IIRC. stdlib-wise I suspect it's even more restricted/different.

pjmlp 9y ago

BeOS, Symbian, macOS, Windows, AS/400, GenodeOS, mbedOS Just a couple of examples.

waddlesplash 9y ago
BeOS' kernel itself didn't use C++ if I recall correctly, though some drivers did. Haiku, BeOS' open-source successor, has a kernel written almost entirely in C++.