There are implementations of STL that do not throw exceptions, and rumor has it they can be used in the kernel. I’ve always been a little wary of those; STL tends to be pretty free with memory, and memory churn in a driver is undesirable.
we’ll all be writing drivers in Rust soon, so we won’t have to have this debate much longer.
Yes, Rust. The new Microsoft’s toy. As it already has become a tradition, others look where Microsoft goes, then rush in the opposite direction.
The same will happen with Rust, mind my word.
@mm About your example - C++ language exceptions are very different from “asynchronous” exceptions, aka signals. The latter generally may occur when the program state is corrupted (like memory overwrite) so should not be recovered by a language exception handler. So it’s not a good example here.
– pa
Ok, If I’m right, then there’s no problem using stl even with exceptions, if you write code in a certain way, just don’t allow expressions that can throw exceptions…?)
Seriously? Do you actually program in C++ or is this something you’re thinking about starting?
OK… the answer: You read the documentation. If a method can raise, it’ll be documented. Because, if it’s not documented to raise, you can’t be ready to catch the exception, right?
Remember, even if you never TRIGGER an exception, the mere fact that a function includes code to throw an exception means that it has to call run-time library routines to set things up. Those runtime library routines are not present in the kernel run-time. So, it’s not that “you can’t throw an exception”, it’s that “you can’t compile any code that MIGHT throw an exception.”
Why stop at 17? The compiler supports a lot of c++20 already. The new bit library in c++20 is useful for systems level work. The new bit_cast offers a another safer and highly useful cast compared to the old c cast. There are now designated initializers for initializing structure fields. And much more. The language just keeps getting better like getting on a highway that is wider, smoother, and straighter than before.
Considering you saw how much/little peeps on the board have used C++ in
kernel, would it not be more prudent to try all these questions yourself?
I bet at best, apart from the audio miniports and trying out exceptions,
noone has any idea, really.
As someone mentioned, this discussion has moved from no-way to maybe… on a
board that did not do such a thing before
My two pennies