5 ms·

C codebases can often be updated with minor changes to compile with a C++ compiler, after which C++ features can be gradually introduced. Is the Linux kernel di

C codebases can often be updated with minor changes to compile with a C++ compiler, after which C++ features can be gradually introduced. Is the Linux kernel different in this regard?

creeble 2y ago
Read the LWN comments.
- Groxx 2y ago
  From a moderate skim, I'm not seeing much in there that really addresses this beyond FUD and over-simplification. Which, I mean... it's the Internet. That's kinda expected. But if there's something specific you're seeing, could you link to it? I'm curious as well what the "stick to C" crowd's reasons are. "C plus this one feature of C++" seems rather defensible at a glance (ignoring the social difficulty in choosing which feature), but I'm sure it's much more complicated than that in practice.
  - dzaima 2y ago
    Even if a project can choose some specific feature(s) to switch to C++ for, it'd severely reduce the barrier for adding reliance on more features; why did feature X get a pass, but not this other one? And C++ has a lot of such potential features that are harmless and easy to justify at their best, but can become headaches when used more broadly, requiring everyone and everything to deal with them.
    - Groxx 2y ago
      The social aspects are very large and it wouldn't surprise me at all if that was by far the main reason... but that's much less of an issue in a kernel-like context where there are already oodles of rules beyond "write valid C code". They can and do impose significant limitations on the languages they use, successfully, for decades. Seems like they'd be able to do that with C++ too.
  - jonathrg 2y ago
    There is a comment purporting to show a difference between compilation speeds in C and C++ which uses iostream for the C++ example, which completely misses the point. Sure C++ has a lot of warts, but in terms of compilation speed it should be completely reasonable to use a few simple template functions.
    - Groxx 2y ago
      Yeah, that's the main thing I saw and it's just plain completely wrong. The fact that C++ can more easily bloat into large build times, and people frequently make larger-build-time projects in it, implies absolutely nothing about its behavior in replacing simple macros like max/min. There's ample evidence that it'll build just a fast as C there, so it's not an issue in this context, and that both can build quickly with care. That's kinda the point of C++: you can write plain C code plus [this one thing] and you basically don't pay for the rest, and it generally achieves that.
- jonathrg 2y ago
  They do not address the question at all. Please write an answer yourself.
  - wahern 2y ago
    The specific macro discussed in the article is using various GCC builtins to safely support mixed integer types; i.e. failing on unsafe type promotions or coercion, but otherwise working automagically. C++ std:min, by contrast, requires all the values to be the same type. AFAIU, to accomplish the same semantics in C++ would require either template metaprogramming, or doing something similar to what the current version is doing with macros and GCC builtins. A C++ solution might ultimately be cleaner, but I don't think there's anything in the standard C++ library that is a drop-in replacement.
    - creeble 2y ago
      Nor would it perform well during compilation, which is very well discussed in the thread. C++ compilation is slow, like the macro expansion of the C versions of min and max. It’s all in the thread, I don’t know how GP missed it.
jcelerier 2y ago
$ cd /usr/src/linux $ rg ' class;' vmlinux.h 8541:struct class; 13515: long unsigned int class; 16416: unsigned int class; 16917: u8 class; 17351: u8 class;
- jenadine 2y ago
  Yes, with minor changes. A few variables need to be renamed, a few cast need to be added. Some churn for sure on such big codebase, but doable nevertheless. GCC did it, other projects did it, I don't see why the kernel can't.
samatman 2y ago
Yes. https://harmful.cat-v.org/software/c++/linus https://harmful.cat-v.org/software/c++/linus
spc476 2y ago
At this point, C and C++ are not compatible. Please stop with this "Oh, just compile C with a C++ compiler." That ship has sailed over twenty years ago with C99. One major difference is designated initializers, which works differently between C and C++ [1]. And C also allows structure literals in function calls: cgci = XCreateGC( display, window, GCForeground | GCBackground | GCFont, &(XGCValues) { .foreground = ccwhite, .background = ccblack, .font = cfont->fid, } ); [1] C++ requires the fields to be initialized in order; C doesn't have this restriction.
- wahern 2y ago
  Compound literals are especially pernicious[1] because GCC and (I think) clang support them in C++ mode, but they have expression lifetime like C++ temporary objects, not block lifetime as in C. That's a guaranteed recipe for dangling pointers and stack smashing/snooping. [1] From a C++ is just a C superset perspective. In C compound literals are awesome.
kzrdude 2y ago
I think the obvious one is that the Linux kernel is no small little project, and any tree-wide change is highly non-trivial. The compressed current source release is 138 MB. A 2021/5.11 lines of code figure I found was 30.3 million. It's not impossible, but the Linux kernel is quite a complex project.

C codebases can often be updated with minor changes to compile with a C++ compiler, after which C++ features can be gradually introduced. Is the Linux kernel different in this regard?

creeble 2y ago

Read the LWN comments.

Groxx 2y ago
From a moderate skim, I'm not seeing much in there that really addresses this beyond FUD and over-simplification. Which, I mean... it's the Internet. That's kinda expected. But if there's something specific you're seeing, could you link to it? I'm curious as well what the "stick to C" crowd's reasons are. "C plus this one feature of C++" seems rather defensible at a glance (ignoring the social difficulty in choosing which feature), but I'm sure it's much more complicated than that in practice.
- dzaima 2y ago
  Even if a project can choose some specific feature(s) to switch to C++ for, it'd severely reduce the barrier for adding reliance on more features; why did feature X get a pass, but not this other one? And C++ has a lot of such potential features that are harmless and easy to justify at their best, but can become headaches when used more broadly, requiring everyone and everything to deal with them.
  - Groxx 2y ago
    The social aspects are very large and it wouldn't surprise me at all if that was by far the main reason... but that's much less of an issue in a kernel-like context where there are already oodles of rules beyond "write valid C code". They can and do impose significant limitations on the languages they use, successfully, for decades. Seems like they'd be able to do that with C++ too.
- jonathrg 2y ago
  There is a comment purporting to show a difference between compilation speeds in C and C++ which uses iostream for the C++ example, which completely misses the point. Sure C++ has a lot of warts, but in terms of compilation speed it should be completely reasonable to use a few simple template functions.
  - Groxx 2y ago
    Yeah, that's the main thing I saw and it's just plain completely wrong. The fact that C++ can more easily bloat into large build times, and people frequently make larger-build-time projects in it, implies absolutely nothing about its behavior in replacing simple macros like max/min. There's ample evidence that it'll build just a fast as C there, so it's not an issue in this context, and that both can build quickly with care. That's kinda the point of C++: you can write plain C code plus [this one thing] and you basically don't pay for the rest, and it generally achieves that.
jonathrg 2y ago
They do not address the question at all. Please write an answer yourself.
- wahern 2y ago
  The specific macro discussed in the article is using various GCC builtins to safely support mixed integer types; i.e. failing on unsafe type promotions or coercion, but otherwise working automagically. C++ std:min, by contrast, requires all the values to be the same type. AFAIU, to accomplish the same semantics in C++ would require either template metaprogramming, or doing something similar to what the current version is doing with macros and GCC builtins. A C++ solution might ultimately be cleaner, but I don't think there's anything in the standard C++ library that is a drop-in replacement.
  - creeble 2y ago
    Nor would it perform well during compilation, which is very well discussed in the thread. C++ compilation is slow, like the macro expansion of the C versions of min and max. It’s all in the thread, I don’t know how GP missed it.

jcelerier 2y ago

$ cd /usr/src/linux $ rg ' class;' vmlinux.h 8541:struct class; 13515: long unsigned int class; 16416: unsigned int class; 16917: u8 class; 17351: u8 class;

jenadine 2y ago
Yes, with minor changes. A few variables need to be renamed, a few cast need to be added. Some churn for sure on such big codebase, but doable nevertheless. GCC did it, other projects did it, I don't see why the kernel can't.

samatman 2y ago

Yes. https://harmful.cat-v.org/software/c++/linus https://harmful.cat-v.org/software/c++/linus

spc476 2y ago

At this point, C and C++ are not compatible. Please stop with this "Oh, just compile C with a C++ compiler." That ship has sailed over twenty years ago with C99. One major difference is designated initializers, which works differently between C and C++ [1]. And C also allows structure literals in function calls: cgci = XCreateGC( display, window, GCForeground | GCBackground | GCFont, &(XGCValues) { .foreground = ccwhite, .background = ccblack, .font = cfont->fid, } ); [1] C++ requires the fields to be initialized in order; C doesn't have this restriction.

wahern 2y ago
Compound literals are especially pernicious[1] because GCC and (I think) clang support them in C++ mode, but they have expression lifetime like C++ temporary objects, not block lifetime as in C. That's a guaranteed recipe for dangling pointers and stack smashing/snooping. [1] From a C++ is just a C superset perspective. In C compound literals are awesome.

kzrdude 2y ago

I think the obvious one is that the Linux kernel is no small little project, and any tree-wide change is highly non-trivial. The compressed current source release is 138 MB. A 2021/5.11 lines of code figure I found was 30.3 million. It's not impossible, but the Linux kernel is quite a complex project.