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 …
@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.
@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…
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.
The Linux kernel is entirely in C with a smattering of assembler. There is no C++ at all, not for any technical reason, but because Linus Torvalds is personally allergic to C++. It is a particularly idiomatic C, nearly free of comments, and they use macros to simulate the kinds of data structures that are easy in C++.
@Tim_Roberts said:
The Linux kernel is entirely in C with a smattering of assembler. There is no C++ at all, not for any technical reason, but because Linus Torvalds is personally allergic to C++. It is a particularly idiomatic C, nearly free of comments, and they use macros to simulate the kinds of data structures that are easy in C++.
I am not a linux dev myself, but my colleague told me that one of the reasons why Linux Kernel is C only is that some platforms simply don’t have c++ compiler implemented for them (I think he was speaking about embedded systems)
The Linux kernel is tightly bound to gcc. Once there is a port to a processor, that means you automatically get C and C++ (and Fortran and Pascal, for that matter).
@Tim_Roberts said:
The Linux kernel is tightly bound to gcc. Once there is a port to a processor, that means you automatically get C and C++ (and Fortran and Pascal, for that matter).
Does It mean that I can actually write drivers for linux in c++ as long as I don’t care about integrating my driver in official kernel sources ?
@Tim_Roberts said:
… but because Linus Torvalds is personally allergic to C++.
To C++ in its state when Linux was founded. That’s C++ 98 or older, and it was then not a clear winner over C (with extra tools).
and they use macros to simulate the kinds of data structures that are easy in C++.
But the C++ data structures are in its standard library, and this library is written in assembly or C.
This library is part of the kernel, it needs to be build for kernel environment, reviewed and maintained.
There’s no miracles. It is made of extra memory and CPU cycles. Every time one uses a C++ thing in kernel, they cannot avoid thinking: will it do a trick under the covers: allocate something? execute something? could it be easier and safer to just use plain C with macros?
By contrast, structures in python or js are magical, one can use them without importing anything and even knowing what’s the name of or {}.
Of course this magic is expensive and doesn’t fit in the kernel. But every time I write something in python - after years of C - I smile (and thank you, Mr, Roberts again for hinting me to learn python!)
Does It mean that I can actually write drivers for linux in c++ as long as I don’t care about integrating my driver in official kernel sources ?
Well, technically there is nothing that stands in your way, although you have to take care of quite a few issues. To begin with, you have to implement your own versions of new() and delete() operators . Furthermore, making C++ work with Linux kernel headers does not really seem to be the easiest job in existence, so that you will probably have to provide your own wrappers for the kernel functions that you call. You must always keep in mind that there is no C++ runtime in the Linux kernel so that you have to avoid certain C++ language features( like , for example, exceptions),et,etc, etc…
When it comes to deciding upon the practical usefulness of this approach…well, this is already a different story that happens to be well beyond the scope of this discussion
> @“Peter_Viscarola_(OSR)” said: > (Quote) > It’s been done. Google is your friend. > > Peter I asked this question exactly because I used google to figure out Linux kernel + c++ viability. And my impression was that you will have to fight really hard with build system to make it work. However mr Robert’s message sounded to me like you basically need just write c++ code in cpp files - pretty much the same way as I do in drivers for windows. Maybe I just misunderstood.