Using "C with classes" would seem to offer some advantages even without the C++ libraries.

1 members found this post helpful.

hm, yes

in C++ you do not pay for something that you do not use, nothing is added by magic.
either you include it as code that is generated or you decide to link agains, if you don't you dont have it in the binary.


yes, this is language agnostic and the Linux kernel requires C but no C libraries functions that do not exist in kernel space,
that's why I said use C where you have to, but this is a design decision, not a god given rule

valid for the Linux kernel, not for say haiku, where the kernel is written in C++, for example look at
https://cgit.haiku-os.org/haiku/tree/src/ in general
https://cgit.haiku-os.org/haiku/tree/src/system/kernel in special

Don't those statements contradict each other?

There should be no problem writing efficient Linux kernel code in C++ provided it doesn't use any library functions "that do not exist in kernel space".

I see no contradiction, yes it should be possible to write efficient Linux kernel code in C++, as you do it for other operation systems, but common sense is to use C for Linux since the design decision was taken.

Arguments that start with "common sense" tend to raise the hairs the back of my neck. Yes, the kernal has been written in C but that doesn't mean that it couldn't be written in C++ nor that C++ couldn't be used in future upgrades.

The end result should still be the same but the judicious use of classes could reduce the incidence of bugs or difficult-to-track programming errors.

It could, technically.
Considering Linus' stance on C++, very unlikely..

(It is hard to argue with LT, for two reasons: 1. he is practically a troll 2. he is actually a programmer who knows what he is talking about.)

well, if you clip away what was in front that you of course miss that I not only basically agree with you that C++ for a kernel is possible but also show examples where it is used. And I also always say that C++ is not just as efficient but also a saver choice, of course only for those who understand how to use it correct.
And there are also posts from me in such discussions that mention that the destructor guarantee is a great thing and I would not want to live without it.
But bad programmers wirte also bad and buggy code in C++, so even if I agree that is is much simpler through RAII and destructor to produce error save and secure code, in practice I see less code bug free/reduced through the choice of the language than through the choice of the developer team doing the tasks.

1 members found this post helpful.

All of that I agree with.

ftfy.

1 members found this post helpful.

In all of the various operating systems whose guts I have explored (in very considerable depth, BTW ...), "kernel space" necessarily plays by very different rules from the comfy-cozy "user land" that it creates. Furthermore, as in the case of Linux, it quickly becomes architecture/model specific. In other words, the programmers who work on the thing really have to k-n-o-w exactly what sort of object-code is being produced. I'm rather of the opinion that C++ would "get in the way" more than it would be beneficial to the present effort ... and that switching all or part of the code base to it would be a business-risk impossible to justify.

1 members found this post helpful.

Considering that nobody has noticed that I said, "judicious use of classes", you are probably right.

I gave up C++ 4 years ago and went back to good old C. Since then I am much more productive.

The hidden benefits are:

1. I don't give a damn about template meta programming.
2. And I couldn't care less what a pure virtual friend base destructor pointer to member-function private protected pointer reference is.

ad 1) so you gave up type safety by using void* all over the place combined with the macros everyone loves, or by simply copy and past the same code snippets just with different types, however not an improvement at all, no teven a hidden one.

ad 2) granulation that you are able to copy from the internet, even if the sentence makes non sense at all, but if proves your trolling attempts, which are, of course, of very low quality. If your train hard you next trolling attempt may become better.

Ladies, gentlemen, let's not insult one another with words like "troll." It's impolite, at best.

The purpose of C++ was to extend the C language to give it object-orientation. (The first C++ was a source-code preprocessor which emitted C output.) It could well be argued that it has since gone overboard ... as did ADD 1 TO COBOL GIVING COBOL.

When you are writing an operating-system kernel, running in kernel space and on an unpredictable architecture, I think that you really do need the precise control that C mixed with asm{ ... } gives you. You need to know at all times exactly what the source-code you are writing will translate into. You are writing to a very spartan environment. You are writing for a very specialized purpose.

In user-land, C++ might be a very efficient way to write source-code because it lets you write less, and because it improves the ability of the language to detect spelin errurs, things that in are the wrong place, and things that you simply lef ... But it would get in the way in the kernel project.

There's really no issue of efficiency: the back-end of the gcc suite is very heavily optimized for all of the architectures for which it runs. Every source-language that you feed into it becomes more-or-less the same stuff when it goes to the back-end to become object code.