4 ms·

Can't disagree with the idea of having C++ in an os kernel strongly enough. It has certainly been tried and in the cases I know of, regretted.

by harry8 5y ago

quotemstr 5y ago
> Can't disagree with the idea of having C++ in an os kernel strongly enough Why? How, precisely, does C++ hurt? > It has certainly been tried and in the cases I know of, regretted. Did it? Fuchsia didn't regret C++ in the kernel. GDB didn't regret moving to C++. (I know GDB isn't the kernel, but it's systems-y.) Android's libc, Bionic, is also written in C++. Every single argument I've seen against C++ in systems code has been specious: people act like typing "g++" instantly implants a copy of the GoF book in your head and turns you into a design patterns robot. "I don't like it" is not a technical argument. Neither is a profanity-laced rant, as satisfying as it might be to pound out such a thing. You can just use C++ as a safer C. Linux would have gotten huge rewards in both safety and developer efficiency if LKML hadn't spent a decade doubling down on their nonsense arguments against C++.
- inglor_cz 5y ago
  Symbian OS was AFAIK written in a specific dialect of C++ as well.
  - varajelle 5y ago
    Every C++ project is written in some dialect of C++
  - harry8 5y ago
    At least one of the L4 implementations. IBM's K42. I think one of the windows kernels tried it once then reverted? Or did every single windows kernel use C too? Symbian really hit a wall taking Nokia down with it. The N95 was well established in the market before the iphone hit but they couldn't get the slow out. Blame it on C++, something else, whatever. C++ is fine for systems code done tastefully. GDB, GCC, libc, java, go nuts! Kernel, not so much. There's a few things going on. You have to agree on a subset of C++ which is a royal bloody pain in the backside at best. It's like a bracing style meeting where the issues actually matter. Some of this is decided for you, you can't have exceptions. Now you can't have operator overloading either. Now constructors are a bit of an issue to consider fairly deeply, "YOU'RE KIDDING YOU'RE SO WRONG I HATE YOU!" And I don't even know what you think about it yet! ;-) Now do that with thousands of contributors. Nasty. Google and Fuchsia? I think they've already got rid of most contributors with the CLA. https://cla.developers.google.com/about/google-individual https://cla.developers.google.com/about/google-individual I couldn't find an actual license and didn't feel like curling to bash to find out what's in the code. It's not surprise that most who try it have a microkernel based system. It is doable. It's been done! Criticising Linus for refusing to go that way seems a little naieve to me tbh. He can point at considerable success as a result of his fundamental approach. That may not be the end of it. But it clearly wasn't a disaster. Critics haven't managed to achieve the success the early days of linux yet as far as I'm aware. C++ compilers have universally sucked incredibly hard until fairly recently when gcc and clang really lifted the standard. No the crooks at intel and the way they sabotaged their customers to make their competitors look bad do not count. They lost the right to be taken seriously at that point. C++ for cross platform has been horrible until very recently. A = B + C + D; You know exactly what that does in C without thinking. C++ not so much. Having those extra layers of thought required between the reader and the machine is unpleasant for OS stuff. C++ has its place. Many of its features are extremely useful and seductive. Many can be used tastefully in userspace to make better, stronger, more reliable code. The Kernel? I don't see it . You want to do dynamic dispatch in C. You can see exactly how that will work on the machine. Virtual functions. No, there's magic there. The implementation isn't guaranteed and can change. There are simply more corner cases, gotchas, foot guns and nastiness where you really don't want it. Kernels are hard enough.
- sseagull 5y ago
  > Every single argument I've seen against C++ in systems code has been specious: people act like typing "g++" instantly implants a copy of the GoF book in your head and turns you into a design patterns robot. "I don't like it" is not a technical argument. Neither is a profanity-laced rant, as satisfying as it might be to pound out such a thing. Well put. Given the style of C used in the linux kernel, it should have been possible to restrict the use of C++ in the same way. Yes there is lots of bad C++ in there, but it doesn't have to make its way into the kernel. The maintainer s can reject code that is uses inheritance, or templates in the wrong way, etc. It's like believing you shouldn't use C in the kernel because it's possible to write lines that are over 80 characters long.
pjmlp 5y ago
Symbian, BeOS, Apple, Microsoft, ARM, Arduino, Google, IBM don't seem to much regretted about their decisions. And no, it wasn't C++ that killed Symbian or BeOS.
- cturner 5y ago
  BeOS kernel was written in C, "It may come as a surprise to some BeOS developers that in our wonderful, buzzword-enabled, OO-powered OS, there is not a single line of C++ code in the kernel." (https://www.haiku-os.org/legacy-docs/benewsletter/Issue4-39.html https://www.haiku-os.org/legacy-docs/benewsletter/Issue4-39....) Windows NT kernel was all C apart from bits of the graphics layer - friction from that team's use of C++ is a theme in /Showstopper/.
  - pjmlp 5y ago
    Windows NT does C++ on the kernel since Vista. Naturally they did not rewrite everything from scratch, just opened the door for new code to use C++. As for BeOS, well I never seen the kernel and Haiku doesn't count.
- secondcoming 5y ago
  Whoa, Symbian's C++ was quite different to the C++ most people understand. 2-phase construction, no exceptions (Leaves and Traps), no string type (Descriptors). It was quite difficult to write, and new hires had to essentially be retrained. Expecting an app ecosystem to be built on Symbian C++ was unrealistic. It's the lack of an ecosystem that killed it really.
  - pjmlp 5y ago
    Symbian's C++ is still C++, not C.
    - secondcoming 5y ago
      In the same way that Medieval English is still English.

Can't disagree with the idea of having C++ in an os kernel strongly enough. It has certainly been tried and in the cases I know of, regretted.

by harry8 5y ago

Can't disagree with the idea of having C++ in an os kernel strongly enough. It has certainly been tried and in the cases I know of, regretted.

quotemstr 5y ago

> Can't disagree with the idea of having C++ in an os kernel strongly enough Why? How, precisely, does C++ hurt? > It has certainly been tried and in the cases I know of, regretted. Did it? Fuchsia didn't regret C++ in the kernel. GDB didn't regret moving to C++. (I know GDB isn't the kernel, but it's systems-y.) Android's libc, Bionic, is also written in C++. Every single argument I've seen against C++ in systems code has been specious: people act like typing "g++" instantly implants a copy of the GoF book in your head and turns you into a design patterns robot. "I don't like it" is not a technical argument. Neither is a profanity-laced rant, as satisfying as it might be to pound out such a thing. You can just use C++ as a safer C. Linux would have gotten huge rewards in both safety and developer efficiency if LKML hadn't spent a decade doubling down on their nonsense arguments against C++.

inglor_cz 5y ago
Symbian OS was AFAIK written in a specific dialect of C++ as well.
- varajelle 5y ago
  Every C++ project is written in some dialect of C++
- harry8 5y ago
  At least one of the L4 implementations. IBM's K42. I think one of the windows kernels tried it once then reverted? Or did every single windows kernel use C too? Symbian really hit a wall taking Nokia down with it. The N95 was well established in the market before the iphone hit but they couldn't get the slow out. Blame it on C++, something else, whatever. C++ is fine for systems code done tastefully. GDB, GCC, libc, java, go nuts! Kernel, not so much. There's a few things going on. You have to agree on a subset of C++ which is a royal bloody pain in the backside at best. It's like a bracing style meeting where the issues actually matter. Some of this is decided for you, you can't have exceptions. Now you can't have operator overloading either. Now constructors are a bit of an issue to consider fairly deeply, "YOU'RE KIDDING YOU'RE SO WRONG I HATE YOU!" And I don't even know what you think about it yet! ;-) Now do that with thousands of contributors. Nasty. Google and Fuchsia? I think they've already got rid of most contributors with the CLA. https://cla.developers.google.com/about/google-individual https://cla.developers.google.com/about/google-individual I couldn't find an actual license and didn't feel like curling to bash to find out what's in the code. It's not surprise that most who try it have a microkernel based system. It is doable. It's been done! Criticising Linus for refusing to go that way seems a little naieve to me tbh. He can point at considerable success as a result of his fundamental approach. That may not be the end of it. But it clearly wasn't a disaster. Critics haven't managed to achieve the success the early days of linux yet as far as I'm aware. C++ compilers have universally sucked incredibly hard until fairly recently when gcc and clang really lifted the standard. No the crooks at intel and the way they sabotaged their customers to make their competitors look bad do not count. They lost the right to be taken seriously at that point. C++ for cross platform has been horrible until very recently. A = B + C + D; You know exactly what that does in C without thinking. C++ not so much. Having those extra layers of thought required between the reader and the machine is unpleasant for OS stuff. C++ has its place. Many of its features are extremely useful and seductive. Many can be used tastefully in userspace to make better, stronger, more reliable code. The Kernel? I don't see it . You want to do dynamic dispatch in C. You can see exactly how that will work on the machine. Virtual functions. No, there's magic there. The implementation isn't guaranteed and can change. There are simply more corner cases, gotchas, foot guns and nastiness where you really don't want it. Kernels are hard enough.
sseagull 5y ago
> Every single argument I've seen against C++ in systems code has been specious: people act like typing "g++" instantly implants a copy of the GoF book in your head and turns you into a design patterns robot. "I don't like it" is not a technical argument. Neither is a profanity-laced rant, as satisfying as it might be to pound out such a thing. Well put. Given the style of C used in the linux kernel, it should have been possible to restrict the use of C++ in the same way. Yes there is lots of bad C++ in there, but it doesn't have to make its way into the kernel. The maintainer s can reject code that is uses inheritance, or templates in the wrong way, etc. It's like believing you shouldn't use C in the kernel because it's possible to write lines that are over 80 characters long.

pjmlp 5y ago

Symbian, BeOS, Apple, Microsoft, ARM, Arduino, Google, IBM don't seem to much regretted about their decisions. And no, it wasn't C++ that killed Symbian or BeOS.

cturner 5y ago
BeOS kernel was written in C, "It may come as a surprise to some BeOS developers that in our wonderful, buzzword-enabled, OO-powered OS, there is not a single line of C++ code in the kernel." (https://www.haiku-os.org/legacy-docs/benewsletter/Issue4-39.html https://www.haiku-os.org/legacy-docs/benewsletter/Issue4-39....) Windows NT kernel was all C apart from bits of the graphics layer - friction from that team's use of C++ is a theme in /Showstopper/.
- pjmlp 5y ago
  Windows NT does C++ on the kernel since Vista. Naturally they did not rewrite everything from scratch, just opened the door for new code to use C++. As for BeOS, well I never seen the kernel and Haiku doesn't count.
secondcoming 5y ago
Whoa, Symbian's C++ was quite different to the C++ most people understand. 2-phase construction, no exceptions (Leaves and Traps), no string type (Descriptors). It was quite difficult to write, and new hires had to essentially be retrained. Expecting an app ecosystem to be built on Symbian C++ was unrealistic. It's the lack of an ecosystem that killed it really.
- pjmlp 5y ago
  Symbian's C++ is still C++, not C.
  - secondcoming 5y ago
    In the same way that Medieval English is still English.