The Linux Kernel Now Explicitly Uses GNU89, Not Yet C11 Friendly

[phoronix]

Phoronix: The Linux Kernel Now Explicitly Uses GNU89, Not Yet C11 Friendly

While the Linux kernel is constantly improving, it cannot yet be built as C11 code...

http://www.phoronix.com/vr.php?view=MTg0MTQ

[Grawp]

Why not rewrite Linux in C++(11)?
Just using namespaces and structs with member functions alone would enhance readability significantly with absolutely no overhead.

[paintbynumbers]

Why not rewrite Linux in C++(11)?
Just using namespaces and structs with member functions alone would enhance readability significantly with absolutely no overhead.

Mostly because existing kernel developers prefer C. Another factor I see cited frequently is that the C++ ABI is defined more loosely than the C ABI.

[mmstick]

Why not rewrite Linux in C++(11)?
Just using namespaces and structs with member functions alone would enhance readability significantly with absolutely no overhead.

Linus hates C++ and has no faith in the programming ability of C++ programmers.

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

[gigaplex]

Why not rewrite Linux in C++(11)?
Just using namespaces and structs with member functions alone would enhance readability significantly with absolutely no overhead.

Because that would take years to do, assuming the main kernel maintainers actually want to change the language.

[nanonyme]

This sounds good to me. It was pretty awful there was a C (sub)standard assumption instead of being explicit. Now at least compiling will loudly and early fail if compiler does not support gnu89

[pythoneer]

Why not rewrite Linux in C++(11)?
Just using namespaces and structs with member functions alone would enhance readability significantly with absolutely no overhead.

not using c++ is a barrier for people who have no clue about systemprogramming or programming at all. the harder one insists on c++ the more likely it is that he should not contribute to the kernel

[gilboa]

Why not rewrite Linux in C++(11)?
Just using namespaces and structs with member functions alone would enhance readability significantly with absolutely no overhead.

Have you taken the time to look at the kernel source before pressing the submit button?
Hint: You can (easily) write *object oriented* code in C and the Linux kernel already does it.

Oh and C++ code, especially when you start using operators, templates and multiple inheritance, is far less readable than C code as its nearly impossible to match the trashed assembly code with the actual C++ code.

- Gilboa

[Grawp]

not using c++ is a barrier for people who have no clue about systemprogramming or programming at all. the harder one insists on c++ the more likely it is that he should not contribute to the kernel

Have you taken the time to look at the kernel source before pressing the submit button?
Hint: You can (easily) write *object oriented* code in C and the Linux kernel already does it.

Oh and C++ code, especially when you start using operators, templates and multiple inheritance, is far less readable than C code as its nearly impossible to match the trashed assembly code with the actual C++ code.

- Gilboa

Well, I've seen a small section of the Linux. I've ported the iMX233 SoC audio driver from 2.6.x kernel to 3.10+. I don't see how adding a little of syntactic sugar would hurt. Multiple inheritance has to be used with some care! but templates are just juicy macros with type checking and operators are ordinary functions with a little different syntax. Anyway I don't propose to utilize all features of C++ (and hell, I absolutely don't propose to use STL, that would be pure insanity.)

Just simple things ... why use fifo_add_function(fifo *f, thing) when one could use fifo_instance.add(thing)?
Why use prefixes like ieee80211_ when one could use namespaces?

I've actually debugged assembly generated from C++ few times. Most of the time it's not different from assembly generated from C. Member function symbols are nicely prefixed, templates have instance numbers. Anyway, how many times one debugs assembly beside when writing scheduler-dispatcher? And HW initialization functions are usually written directly in assembly.

[computerquip]

I see no reason for remaking code in C++. I do see a reason to provide a C++ interface for drivers that wish to use C++. The way the codebase is now, it clearly was designed around ignoring the existence of C++. A lot of driver interfaces is really just a structure of function pointers. It's the definitions of the interfaces of other utilities from the Linux kernel that are a bother, most of which assume C++ isn't there. But really, if you make your own definitions, you could probably even pull off making a new driver in D if you really wanted to (and got the environment right). However, I'm not sure of any linker quirks or GCC quirks one should be aware of, so it may be more complicated than that.

EDIT: Inline functions and macros are also a problem. You'll have to recreate most of them and all of them if you aren't using a C* language.

Btw, C11 does allow for type-based macros using _Generic.