Hacker News Reader

Hacker News

Comment by tbodt | Hacker News Reader

Parent Full thread

tbodt

> In fact, in Linux we did try C++ once already, back in 1992.

> It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

https://lkml.org/lkml/2004/1/20/20

View on HN

A 14-year old opinion based on a 26-year old experiment.

C++ has evolved tremendously since. There are better arguments.

(and I say this as a C developer who doesn't believe C++ is the right answer)

With no solid ABI it is unlikely.

Is that a likely problem for the kernel, actually? Given that there's no API stability, and the fact that syscalls are an explicit ABI anyway, I don't see how that'd matter for linux?

(not that I'm arguing for C++ in linux or such)

Sorry, Just my sour grapes.

Recently created a third party SDK DLL in c++ and could not pass c++ types natively (unless you coupled to compiler and maybe version of compiler).

This is C++ on Windows for you. On Linux, most compilers follow the ABI that GCC created, which has become very stable. I actually cannot name a C++ compiler that doesn't follow that ABI.

Actually, Linux nowadays uses the Itanium C++ ABI (even on non-IA64 architectures), and AFAIK it was created by Intel, not GCC.

I stand corrected. Indeed, the Itanium ABI defined by Intel is the base.

The important part is that it is used by most, if not all, C++ compilers on that platform.

Which is why any Windows developer that wants to export OO libraries uses COM instead, with the benefit that any Windows compiler that can speak COM is able to use the library.

UWP now even supports generics and actual inheritance.

Kernel modules?

When using C++, you also need to take into account the compiler ABI.

Does that really matter in the context of the Linux kernel, seeing as GCC is the only supported compiler currently?

One can use the C ABI with C++.

How does that work with templates, overloading, operators, etc?

They aren't exposed to ABI surfaces. Only C compatible stuff would be.

Cf. e.g. Microsoft's CRT implementation, which uses C++ by now, but still exposes a C API.

On Windows that ABI is COM, on Windows 10 it was updated to UWP and is quite feature rich, even if it doesn't support 100% C++ features.

This was 14 years ago. In that time

* C++ has advanced considerably, and features like constexpr, lambas, unique_ptr, etc make writing code easier without runtime overhead.

* The C Compiler that Linux uses, is now written in C++

* Clang tidy checks make it relatively easy to keep problematic C++ features out.

The fact that C++ is largely a superset of C means that just like GCC did, there can be a gradual migration of code.

C++ has advanced considerably

...and gained considerable complexity in the process. (I'm aware that C has gained some too, but not to the extent of C++.)

And I'd wager the Linux kernel has become more complex in the past couple decades too. But so what?

I'd argue: Yes, this is true. But you need at least on stable part in the toolchain for the kernel to get reliable results. You can't have your hammer transform to a screwdriver just because you swing it in the other direction. And if there is such a tool/case, you need to be absolutely sure how and when it behaves this way, on every possible platform.

This is not the case for evolving C++.

To me this situation is more more like having a screwdriver that can only be screwed with hammers from a particular manufacturer (Linux -> GCC), because that manufacturer is the only one that makes hammers with screw-driving tips that work with that particular screw head (non-portable macros for type-checking or whatever goes on there). You might as well just get a normal screwdriver (C++ compiler) and a normal screw (C++ program) like the rest of the world does -- and there's no implication that you have to keep changing screw tips (-std=c++??) every time Apple (standards committee) decides to come up with a new format (C++17).

If you are going to argue that, then you need to look again at the headlined item, where it was not the case that it behaved the same on every possible platform. It is a non-standard mechanism of one compiler, that was picked based upon a compromise decision about what versions even of that one compiler it would actually work with.

It's a true statement that C++ has gained considerable complexity since those days, largely due to the C++ committee's very religious approach to compatibility. How that added complexity has influenced how complex C++ applications must be is a discussion with considerably more nuance.

C language is simple, and the result is this considerably complex piece of implementation instead.

The problem is that you can't always require people to use the latest bleeding edge version to build your code. Especially the Linux kernel has quite some requirements for backwards compat.

And yes, the fact that abi stability isn't really a thing in c++ land is a huge problem too. It has been tried before with beos and it sucked.

Reply on news.ycombinator.com