2 ms·

> Anyone who says C is not important hasn't worked on [..] operating systems. Most OS code is written in C++ or Object-C, not C. Between Android, MacOS/iOS, an

> Anyone who says C is not important hasn't worked on [..] operating systems. Most OS code is written in C++ or Object-C, not C. Between Android, MacOS/iOS, and Windows there's not a lot of C code. The kernels are most of it. The NT kernel has C++, but hard to get a source on how much is still C or not. But the kernel is far from being most of the OS regardless. > The fact that C doesn't require a runtime (nor does Ada), means you can use it to write kernels. You can't do the same with a 'full' version of C++, so you're back to a cut down C++. For a huge number of users, "full" C++ is C++ with -fno-exceptions and -fno-rtti anyway, at which point the 'runtime' is like 2 functions and it's absolutely perfectly fine to use in a kernel. But regardless neither of those features are inherently incompatible with being in a kernel. You just have to implement a runtime to do that, just like kernels written in C have to implement a libc replacement. Unless you're talking about the standard library (even though nearly all of it is completely kernel-compatible out of the box), but then you'd have to include libc & friends in the "C runtime" category and then it's equally impossible to use in a kernel.

phoehne 4y ago
Sorry, I didn’t mean the userland stuff above the kernel, which, along with the boot loader, is the part that is really restricted in any sense. With the standard library, there are large parts that are not kernel safe. That’s because they rely on services like memory allocation, which are different in the kernel. Or they rely on kernel services, like files. And what I work on has no kernel, just an RTOS. And C in the kernel isn’t really a libc replacement. They often have different behaviors because they need to run without allocating memory, or be interrupt safe. For example, in some situations I use a function call instruction that specifically does not creat a new stack frame.
- moloch-hai 4y ago
  Very little of the standard C++ library is not "kernel safe". If a bit of it might need to allocate, you may provide it a kernel-grade allocator to use; but you probably use custom kernel containers, for other reasons. If you don't want any filebufs, you do not make them. And of course asm {} works the same regardless.

phoehne 4y ago

Sorry, I didn’t mean the userland stuff above the kernel, which, along with the boot loader, is the part that is really restricted in any sense. With the standard library, there are large parts that are not kernel safe. That’s because they rely on services like memory allocation, which are different in the kernel. Or they rely on kernel services, like files. And what I work on has no kernel, just an RTOS. And C in the kernel isn’t really a libc replacement. They often have different behaviors because they need to run without allocating memory, or be interrupt safe. For example, in some situations I use a function call instruction that specifically does not creat a new stack frame.

moloch-hai 4y ago
Very little of the standard C++ library is not "kernel safe". If a bit of it might need to allocate, you may provide it a kernel-grade allocator to use; but you probably use custom kernel containers, for other reasons. If you don't want any filebufs, you do not make them. And of course asm {} works the same regardless.