С++ in kernel

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:

I’m sorry, over the past 20+ years of doing this stuff debugging a driver written in anything other than C (no ++ variant) bleeds into a nightmare. Of course the caveat to this is if YOU wrote the driver. If you are debugging some other clients driver and they have implemented a perfectly written OO++ driver, it will take days of stepping through code, and reading their implementation, to understand what is happening. Just write it in C … or assembly! My 2 cents …

1 Like

I agree. The cost of C++ is not to the authors, but to the reviewers and maintainers.

1 Like

@Peter_Scott @MBond2

I agree with you concerning fully OO implementations. Hideous beyond compare.

But… Using C++ does not necessarily imply using an OO design.

We’re talking Modern C++ here… unique_ptr, ranged for, constexpr… nothing hard about debugging or maintaining any of those.

As long as one sticks to “C++ as a better C” you’re good to go.

Peter

@Peter_Scott said:
over the past 20+ years of doing this stuff

Note there are also those using c++ in the kernel 30+ years that have an opposing view. Circa 40 years ago I wrote assembly apps, TSR’s, and drivers for Dos. When Borland and Microsoft introduced the C language for the PC I enthusiastically used it and loved it and got great mileage out of it for years. Today c++20 is my language of choice in windows for both kernel and user mode. Why? Because it blows C out of the water, period.

anything other than C (no ++ variant) bleeds into a nightmare

This is a common misconception that C++ = OO. But it’s not true. When you rename your file extension from .c to .cpp the compiler doesn’t refuse to compile it because there’s no OO in it. On the contrary utilizing powerful c++ language features like a static assert or being able to use sizeof on a field is not a debugging nightmare but actually improves productivity all around. The C++ language is constantly getting refined. Not with OOP garbage, but lots of nuts and bolts basics for those writing kernel drivers. The latest c++20 language is brand new and absolutely awesome for driver developers. Some people don’t know today’s c++20 is nothing like C++ was 10 or 20 years ago. What the standards people have rolled out over the last decade is nothing short of miracles for people writing code.

Just write it in C … or assembly!

Assembly in the kernel makes no sense since sometime in the last century. Too many reasons to list. It’s not cross platform and besides just think of how unreadable your code would become trying to reorder the instructions for super scalar optimization which a c/c++ compiler does for you for free.

@Rourke said:
Some people don’t know today’s c++20 is nothing like C++ was 10 or 20 years ago. What the standards people have rolled out over the last decade is nothing short of miracles for people writing code.

This is precisely the point. Why they haven’t moved their ass 10 years earlier? Was it a rocket science? All these “modern” languages - Go, nimrod, julia, Rust and so on - raised mostly because C++ was not good enough. One can’t claim that they have 5 years of writing new code or maintaining existing code in C++20.

– pa

@Pavel_A said:
This is precisely the point. Why they haven’t moved their ass 10 years earlier? Was it a rocket science? All these “modern” languages - Go, nimrod, julia, Rust and so on - raised mostly because C++ was not good enough. One can’t claim that they have 5 years of writing new code or maintaining existing code in C++20.

– pa

This may have been due to problems with backward compatibility, the need for high performance, and so on. now C++ is developing very dynamically…

I very much agree with Mr @Rourke … which is unusual, because he and I have disagreed on numerous things in the past.

To Mr. @Pavel_A’s comment:

Go, nimrod, julia, Rust and so on - raised mostly because C++ was not good enough

This is a different category of issue. C++ is still “not good enough” for a modern operating system implementation language. Yes, it provides many of the tools to “do things right”_ if you use them_. But it does not force these constructs. I very much like this discussion on Reddit.

Now, before we get too far down the “why is rust great and C++ not so great” road, let me hasten to add that having actually spent time trying to do something useful with rust on Windows, I’m not nearly as enthusiastic about it as I was when I read about the language. In fact, I’m willing to bet that rust’s current popularity (in the “polls of programmers opinions” that we so often read) is due to a lot of people who did the rust-lang hello world, thought “that’s pretty cool” and then stopped. I don’t want to turn this thread into a rant on why rust in general, and particularly using rust on Windows, is frustrating… so I’ll just leave it there.

Peter