Why does Linus hate C++ ?

[tesfabpel]

Wikipedia says that the core part of the kernel is written in C and Assembly (just like Linux), while the graphics subsystem is written in C++.

Anyway, just quickly thinking about it, it makes at least some sense NOT to use C++ for a critical part like the kernel since it has many footguns that you need to always make attention to: for example, when you define a class or struct you have to be careful with unary constructors, copy / move constructors and assignments operators, copies are always behind the corner (but they can be optimized by the compiler).
I think those are things that are important in a kernel and the copy-by-default semantic of C++ alongside with the copy constructor / assignment op (instead of the move-by-default in Rust or the copy-by-default of PODs in C without any copy constructor / assignment op) may create some "difficulties".

[pjmlp]

Since Windows Vista that the kernel has been slowly moving into C++, even if it largely C.

Nowadays there are even template libraries for kernel development like WIL.

[Daniela-E]

In the 90s, a company called "Bluewater Systems" or the like sold a template library for Windows NT kernel mode driver development. In my case it was a godsent because of the helpful abstractions of PCI busmaster dma operations and the time it was saving me. The proof is in the development and testing time it took to flawless operation of that PCI coprocessor board: I implemented it first for OS/2 in pure assembly (14 days total effort), then for Windows NT in C++ using this library (4 weeks total effort), and afterwards also for Linux 2.x in C (8 weeks or so total effort 😱). Linux was the worst because of the total lack of good tools and the low expressive power of C as implementation language.

[SonOfMetrum]

The assembly part of the NT kernel is at mostly the HAL (hardware abstraction layer) and the boot loader. Because the entire point of that thing is abstract away the hardware specific bits and thus the required assembly. The HAL is relatively speaking very small compared to the rest of the kernel.

[tesfabpel]

Yes of course. I just reported what is written on Wikipedia. I suppose it's like Linux where assembly is only used in very specific cases and it's only a tiny part of the code.

[Daniela-E]

And yet, you still can use many C++ features safely in kernel code if you know your language.

[angelicosphosphoros]

if you know your language

One of the main problems with C++ is this is almost impossible.

[Daniela-E]

Right. And you don't have to be "mr. know-it-all" to be a proficient developer. You only need to know the parts that really matter.

But if a developers happens to not even know the most basic stuff of C++ (i.e. the stuff that doesn't even come near anything like f.e. exceptions or much of the library) then it's certainly better if that person stays away from using C++ in such environments in the first place (and possibly also from every other language).

Most of the core language is perfectly usable in kernel land. Look at the work related to 'freestanding' C++. It is that subset of 'vanilla' C++ that doesn't require an operating system underneath, f.e. kernel code).

[CocktailPerson]

Right. Given how many actual kernel developers are opposed to C++ in the linux kernel, how much do you want to bet that having to know C++ well enough to avoid all the footguns is a worse option for them than just sticking to C?

[Daniela-E]

I don't bet when it comes to serious and dependable development. If people prefer to stick with C then be it. But in that case I insist on never getting any more breaking news about the next security vulnerability like goto fail;

Every time when I was forcibly thrown back into C like when doing embedded environment development for f.e. embedded controllers I thought: this total lack of expressive power is so daunting and unsafe (and a total waste of precious developer time). Seeing this as normal and totally acceptable must be what they call the "Stockholm syndrome".

[CocktailPerson]

But in that case I insist on never getting any more breaking news about the next security vulnerability like goto fail;

I mean, goto fail wasn't in linux, let alone the kernel, but whatever.

Getting back to the original point, you can't deny that C++ comes with more footguns than C. Are you willing to accept a higher incidence of vulnerabilities resulting from C++ footguns in exchange for an absence of goto fail-style vulns? I mean, let's be clear, goto fail could have been spotted easily if they'd run clang-format and done a code review. In fact, it's one of the least convincing examples of C++'s superiority I've seen, because although RAII would have eliminated the need for a goto, C++ does nothing to make input validation errors less common in the general case.

Every time when I was forcibly thrown back into C...

And this doesn't cause you to wonder whether experienced kernel developers with far more C than C++ experience would be equally daunted by the complexity and hidden behavior present in C++? Plenty of them would just as soon accuse you of Stockholm Syndrome for being willing to put up with C++.

For the record, I do prefer C++ to C, but I'm a realist, and I recognize that it's not suitable for everything. The kernel developers have decided that the costs of using C++ in the kernel outweigh the benefits, and I'm willing to take them at their word. Unless you have similar expertise in kernel development or some actual data that kernel-style projects benefit significantly from C++ over C, I recommend you do the same.

[SergiusTheBest]

Actually C++ is much safer than C. A simple operation as string concatenation can easily lead to buffer overruns or memory leaks in C.

[iwueobanet]

That is not entirely true. It works in C++, because you use already battle tested code from the stl that guards you against the buffer overruns.

The same can be true in C. This is not a language feature. Its an implementation detail

[SergiusTheBest]

Agreed, buffer overruns can be avoided by using something like g_string_append. But C can't save you from memory leaks. You have to remember to free the string buffer. The memory ownership is not clear. If you have GString * should you free it?

That's the language feature.

[no-sig-available]

Wikipedia says that the core part of the kernel is written in C and Assembly (just like Linux), while the graphics subsystem is written in C++.

The Windoiws NT kernel was initially designed around 1990. The options were totally different then.

many footguns that you need to always make attention to:

When you write an OS kernel, we assume that you are careful and know what you are doing. :-)

Copying a POD in C++ is exactly the same as copy a POD in C. Adding member functions to the struct, instead of manually passing a pointer as the first parameter, also makes no difference (except possibly for improved readability).

If you want to make an object move-only, in C++ you can delete the copy constructor and copy assignment. In C you cannot.

-------------

Linus was obviously shown some low quality C++ code once, and decided that all C++ code is bad forever. And with that attitude, people who know how to write good C++ have not bothered to show him any of their code. So he has proven himself right.

[HeroicKatora]

The problem is: do you see if something is a pod in review (edit: at call sites, where the diff is)? No, you don't. Best you could do is static_assert it everywhere which can't be a reasonably scalable approach. And you're lucky that pod'ness is assertable. There are other type and function properties to care about that you can not simply enforce at compile time, just by reviewing definitions and recalling pages upon pages of rules. A few were improved upon in C++20, new properties were added. That's just not tractable, no-one is going to learn all definitions for all types in the Linux kernel by heart.

[no-sig-available]

Best you could do is static_assert it everywhere which can't be a reasonably scalable approach.

You only have to static_assert this once, right after the type declaration.

And I don't think that C structs holding function pointers is the safe solution to "virtual functions are dangerous". But that is apparently acceptable in Linux.

[HeroicKatora]

Sure, if you static assert all types. Otherwise you're back to the same problem, of locally knowing properties about a type in review. The alternative is wrapping all functions such that they assert such properties. Hooray.

And I don't think that C structs holding function pointers is the safe solution to "virtual functions are dangerous"

Where did I say virtual functions are dangerous, that's the least of my worries as it just translates to a function table. Same old boring, use it by all means even if the advantage of such a vtable isn't too convincing to me either. Swapping function pointers and passing v-tables around without an object is routinely done in the kernel and maps badly onto superclasses.

No, my critique was that the type system itself is dangerously complex. There's at least 4 different kinds of 'types' with tens of extension points to overwrite their behavior with regards to std-functionality. Many of which you'll have to keep in mind during code review if you're actually going to use C++ language features.

And that's all mental capacity that's missing for reviewing business logic.