Any C program, including an OS kernel and its apparatus, can be transitioned seamlessly to C++ in a day, and then modernized at leisure. Ten years is plenty of time for that.
> I wrote ToaruOS at a time when I was much more competent at C than C++. I still think that's true. At this point, the effort of rewriting datastructures to make use of C++ functionality would not be a good use of time - and writing userspace code in C++ in ToaruOS-NIH is not yet possible as I have yet to get a C++ standard library set up.
This is sooooo not true. It might compile with a C++ compiler but they're two entirely different langs and the best code looks very different between the two.
Plus, C++ requires extra setup at the kernel level given the init code. It also requires manually designing your vtables.
Also, verifying C (if you ever go that route) is many times easier than verifying C++.
Also C compiles faster in many cases, easing development.
Plus C doesn't bark at you about certain ASM-isms that are frequently found in kernel code.
Plus C is arguably easier to reason about.
Plus C++ standard library can't be used anyway and auto pointers aren't really that much of a concern at the kernel level
Plus you're doing a lot of init work that never returns thus automatic destructors aren't as useful.
Also C is just fun, and perfectly suited for the task.
"Microsoft's toolchain does not ship a copy of the STL that works in kernel mode. Partly this is because the kernel's CRT doesn't support C++ exceptions. (And partly this is because I/O is wildly different in kernel, so you'd have to rewrite the implementation of all the I/O libraries.)
But for kernel developers, wil ships a subset of an STL implementation. To avoid conflicting with the real STL, it's available under the wistd namespace. The rule of thumb is that wistd::foo is a drop-in replacement for std::foo."
Modern C++ is something nebulous. What is Modern C++ now would be obsolete few years down the line. So clearly maintenance of such a project wouldn’t be much fun, I suppose.
C doesn’t suffer from this for one. You have more time to focus on the task than on managing the myriad ways of doing the same thing.
Modern C++ is whatever is standardized and implemented. Obviously, as new Standards are published, new features become available, and any workarounds for their lack become redundant. But that has not inconvenienced SerenityOS even a little bit.
C++ did not, strictly speaking, exist at that time. I.e., there was no Standard defining it, and most of what makes it useful was not implemented in compilers.
About all proto-C++ had that was actually useful and usable, beyond C, was destructors. That changed by around 2003.
So it was much less mature than even Rust is today.
Yes, when Linus first tried C++ in 1992 this is true. But the linked comments were done in early 2000s which by then C++ was very mature. So by early 2000s, C++ was already 20 years old. Rust is only 11 right now.
You can have great productivity in C++, but it's also a very complex language.
When I code in C, I make many mistakes, but they are all stupid mistakes.
When I code in C++, I sometimes have no clue how to move forward and have to spend hours reading up on the current state of templating or lambdas in the standard library.
The tradeoff is, that you can have larger and more complex program before hitting the brick wall of too many interconnections and fiddly things to change everywhere.
In C it's much more hard work to even reach large and complex because you have to write so much "by hand". And when you do reach high complexity, it's very very much up to enforced patterns and cohesive architecture how hard it is to wrangle.
The good thing about C being hard, is that it makes you think harder about what you can get away with NOT doing.
But if you know you have a bunch of code to write, for me it feels faster to do it in C++ than C.
Maybe this is because the quote "Any sufficiently advanced technology is indistinguishable from magic." would imply that the computer would stop working ? (This was only intended as a pun, as the reason is most likely the author prefers the other set of characters, but having the kernel panic handling module be named Touma would add to the spirit)
For those that would (most understandably) not get the reference in those names, there is a novel saga called "To Aru Majutsu no Index"/"a certain magical index", which the name references (to aru == "a certain"), and Misaka/Kuroko are characters from it.
25 comments
[ 0.29 ms ] story [ 72.6 ms ] threadSerenityOS is in modern C++, and benefits enormously.
> I wrote ToaruOS at a time when I was much more competent at C than C++. I still think that's true. At this point, the effort of rewriting datastructures to make use of C++ functionality would not be a good use of time - and writing userspace code in C++ in ToaruOS-NIH is not yet possible as I have yet to get a C++ standard library set up.
1: https://github.com/klange/toaru-nih/wiki/FAQs
Plus, C++ requires extra setup at the kernel level given the init code. It also requires manually designing your vtables.
Also, verifying C (if you ever go that route) is many times easier than verifying C++.
Also C compiles faster in many cases, easing development.
Plus C doesn't bark at you about certain ASM-isms that are frequently found in kernel code.
Plus C is arguably easier to reason about.
Plus C++ standard library can't be used anyway and auto pointers aren't really that much of a concern at the kernel level
Plus you're doing a lot of init work that never returns thus automatic destructors aren't as useful.
Also C is just fun, and perfectly suited for the task.
https://github.com/microsoft/wil
"Ah, but that isn't used on the Windows kernel" would be the expected reply, well
https://community.osr.com/discussion/291326/the-new-wil-libr...
"Microsoft's toolchain does not ship a copy of the STL that works in kernel mode. Partly this is because the kernel's CRT doesn't support C++ exceptions. (And partly this is because I/O is wildly different in kernel, so you'd have to rewrite the implementation of all the I/O libraries.)
But for kernel developers, wil ships a subset of an STL implementation. To avoid conflicting with the real STL, it's available under the wistd namespace. The rule of thumb is that wistd::foo is a drop-in replacement for std::foo."
C doesn’t suffer from this for one. You have more time to focus on the task than on managing the myriad ways of doing the same thing.
About all proto-C++ had that was actually useful and usable, beyond C, was destructors. That changed by around 2003.
So it was much less mature than even Rust is today.
But Rust is more mature now than C++ was in 2007. Fully self-contained projects can move fast.
Just wait when the first set of monadic libraries full of macros start landing on Linux drivers.
I am quite sure Linus won't be amused, but hey at least it isn't C++. /s
When I code in C, I make many mistakes, but they are all stupid mistakes.
When I code in C++, I sometimes have no clue how to move forward and have to spend hours reading up on the current state of templating or lambdas in the standard library.
The tradeoff is, that you can have larger and more complex program before hitting the brick wall of too many interconnections and fiddly things to change everywhere.
In C it's much more hard work to even reach large and complex because you have to write so much "by hand". And when you do reach high complexity, it's very very much up to enforced patterns and cohesive architecture how hard it is to wrangle.
The good thing about C being hard, is that it makes you think harder about what you can get away with NOT doing.
But if you know you have a bunch of code to write, for me it feels faster to do it in C++ than C.
The languages are very different.
For those that would (most understandably) not get the reference in those names, there is a novel saga called "To Aru Majutsu no Index"/"a certain magical index", which the name references (to aru == "a certain"), and Misaka/Kuroko are characters from it.
By the way, is Yutani a reference to something ?