Surely constructs like scope guards etc. are useful in kernel development as well?
Systemd uses it: https://github.com/systemd/systemd/blob/5809f340fd7e5e6c76e2...
Some people rather use official language features.
... i suppose this project is locked into G-standard C++ and with lots of good reasons (e.g. toolchain). although i'm an anti-C++ person, i suppose the sorts of tools available internal to Alphabet make it much more manageable.
anyway, for an example of the original premise: i'm slowly learning some things about plan 9 C via 9front.. there are some departures from ANSI C, including additional features like (completely undocumented, except for the relatively compact source) operator overloading. equally important for the type of person that finds C++ too busy, some features (e.g. certain preprocessor features) are removed.
It makes managing any resource with acquire/release semantics very easy. It also prevents errors when the code is modified later because you cannot forget to call cleanup code as it is done automatically. I have no experience with kernel programming, but acquire/release seems to be something that is done in the kernel.
Agreed. But microkernels generally don't acquire or release resources. Most people arguing against this point seem to have a monolithic kernel mindset, but microkernels are a whole different beast.
If a kernel owns any kind of resources, that leaves the whole system vulnerable to denial of service attacks. Therefore, microkernels have long since adopted designs where the kernel does not own or allocate anything, and all resources belong to processes (which incidentally makes identifying misbehaving processes easy, something not easy on UNIX kernels).
Any data the kernel requires for its operation is allocated at boot time and lives until the system halts.