3 ms·

I’m curious, why is C bad at the OS level? It seems like having stuff like classes as improved structs would be helpful as long as you avoid pitfalls like virtu

I’m curious, why is C bad at the OS level? It seems like having stuff like classes as improved structs would be helpful as long as you avoid pitfalls like virtual functions/STL containers. C++ compiled without the STL and specific features like virtual seems like entirely an improvement for writing an OS

remexre 3y ago
After you knock out those and exceptions, what's left in (C++98 - C99)? Destructors and templates? 98 won't have moves, so I'd imagine you'd end up boxing most of your structures to avoid needing to copy construct then all over the place. You still have to manually delete things but now there's extra indirection. Templates might be nice, but having STLy containers is where the kernel would need them most, but then above boxing issues start to exist.
- Taniwha 3y ago
  OS's have limits on when you can do some stuff - for example allocating/deleting stuff in an interrupt handler (and the associated code that interacts with it) - mostly you code around this by just not doing it if you possibly can - but C++ might be doing this behind your back. And when you do need to do it you will likely use a special allocator and associated heap that knows how to interact safely with ISRs - just doing a 'new' without being able to say "where" and "how" is a problem. And then you have to be able to delete/free it the correct way too. Essentially it means that an important chunk of the language and standard library are off limits in an important part of an OS, and lots of evil bugs are available to people new to the game who just blindly new stuff (or let the compiler do it behind their back)
  - pjmlp 3y ago
    Usually a lame argument, as ISO C also isn't supported at kernel level.
- pjmlp 3y ago
  RAII, templates and inline instead of macros, safer enums, strong types than plain C as less implicit conversions are allowed, namespaces instead of prefix, classes as modules with proper invariants, safer strings and arrays. Plenty of stuff.

remexre 3y ago

After you knock out those and exceptions, what's left in (C++98 - C99)? Destructors and templates? 98 won't have moves, so I'd imagine you'd end up boxing most of your structures to avoid needing to copy construct then all over the place. You still have to manually delete things but now there's extra indirection. Templates might be nice, but having STLy containers is where the kernel would need them most, but then above boxing issues start to exist.

Taniwha 3y ago
OS's have limits on when you can do some stuff - for example allocating/deleting stuff in an interrupt handler (and the associated code that interacts with it) - mostly you code around this by just not doing it if you possibly can - but C++ might be doing this behind your back. And when you do need to do it you will likely use a special allocator and associated heap that knows how to interact safely with ISRs - just doing a 'new' without being able to say "where" and "how" is a problem. And then you have to be able to delete/free it the correct way too. Essentially it means that an important chunk of the language and standard library are off limits in an important part of an OS, and lots of evil bugs are available to people new to the game who just blindly new stuff (or let the compiler do it behind their back)
- pjmlp 3y ago
  Usually a lame argument, as ISO C also isn't supported at kernel level.
pjmlp 3y ago
RAII, templates and inline instead of macros, safer enums, strong types than plain C as less implicit conversions are allowed, namespaces instead of prefix, classes as modules with proper invariants, safer strings and arrays. Plenty of stuff.