С++ in kernel

Perhaps there can remove the use of exclusions for use in the kernel

I think that’d be a great project for you to undertake.

When you get that done, please be sure to post back here and let us know how it all turned out.

Peter

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.

1 Like

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.

– pa

@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

1 Like

@“Peter_Viscarola_(OSR)” said:
It works (range based for loops) for plain arrays… so, at least there’s that.

Oh wow, I didn’t know that. Cool.

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…?)

Mr. Funky… please. Stop. Think.

You can’t predict what will raise. vector::push_back can raise. Without that, why use std::vector?

So… let’s just leave it at “You can’t use anything that can possibly raise.” OK?

Peter

Peter, thanx you for help! But… How I can known what can raise exception or not?

How I can known what can raise exception or not?

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?

Peter

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.”

1 Like

There are inofficial runtime implementations of the support for exceptions in drivers like https://github.com/avakar/vcrtl

This cyclic discussion has (d)evolved from:
“NO NEVER!” vs “Its OK, with caveats”

To:
“It’s OK with documented limitations” vs “But I need stdlib this or stdlib that”

I guess that is progress.

@Mark_Roddy said:
This cyclic discussion has (d)evolved from:
“NO NEVER!” vs “Its OK, with caveats”

To:
“It’s OK with documented limitations” vs “But I need stdlib this or stdlib that”

Well, like so many other discussions… on the climate, or the damned virus, or possibilty that modern humans have genes of Neanderthals :wink:
– pa

And another question: C++17 standard in Visual Studio for kernel drivers are enabled with /kernel flag?

By default? I dunno. You want 17 or 20 just select it, in the usual way.

Peter

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.

Std::bit… That’s one I hadn’t seen before, and indeed could be quite useful.

Very good Mr. Rourke. Thanks for that suggestion.

Peter

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 :slight_smile:
My two pennies :slight_smile:

@Dejan_Maksimovic: I don’t understand your post. Who are you replying to?

I can tell you, for sure that I’ve built Windows kernel-mode drivers specifying both /std:c++17 and /std:c++latest and they work just fine.

trying out exceptions

Huh? We know exceptions don’t work.

Peter

It is a reply to Alex. I keep forgetting this is not rganized as a list any
more…

Yes, we tried exceptions, and know they do not work. That is about it…
I meant he should try all of it on his/her own.

Are c++17 supported fir kernel? It takes 15 seconds to test, 15 to send the
question snd ask, another 1500 to read the answers :slight_smile:

Let me quote you:
"I think that’d be a great project for you to undertake.

When you get that done, please be sure to post back here and let us know
how it all turned out."

:slight_smile: