2 ms·
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.
by junon 5y ago
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.
- pjmlp 5y ago> Plus C++ standard library can't be used anyway and auto pointers aren't really that much of a concern at the kernel level https://github.com/microsoft/wil 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-library-for-c-code-in-drivers 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."