you guess wrong.
C++ is widely used in the embedded wold, on application level

I do not understand this sentence, maybe because I am not a native english speaker?

That unix OS domain is C is ok, good and I do not advocate to change this, just look some posts up

but as already mentioned, there are vendors that do not even ship a C compiler and they require you to use a C++ compiler for operating system / driver code.
That C++ is not used on OS level is not true
BeOS, now Haiku, is an other example.
so a lot of things said, not just here, about C++ are just somewhere between wrong and stupid and show a huge level of missing knowledge.

I have been creating very sophisticated Linux networking modules for many years and continue to develop them on the very latest Linux kernels. It is not necessary to patch the kernel to do this if you are willing to give up support for exceptions. Don't worry about the rude comments you might receive from some of the Linux fanboys. There is a lot of childishness in the community. I wouldn't patch the kernel. If you don't patch then supporting multiple Linux releases becomes easy. The kernel API is not particularly stable. Or particularly well documented. That is not the Linux way. So you will have to reverse engineer occasionally to figure out how the modified kernel APIs should be used. You will also get "kernel tainted" messages if your driver is not GNU licensed. The non-open-source nvidia drivers gave the same message. But were much finer quality than the open source versions.

My modules are also used, without change, in various embedded environments, including VxWorks. All of those are friendly to C++ and provide full support. And the embedded OSes do not report that the kernel is "tainted." ; )

There are a couple of global symbols used by the C++ runtime, and you will need to write functions for new and delete that call the kernel APIs for these functions. Trivial stuff. A few dozen lines in all.

It is only "tainted" by being a proprietary module that prevent developers from debugging the kernel. If it were GPL then there would be no problem. But it is a proprietary module that is also a derivative of kernel sources, thus the kernel is "tainted".

The other "OSes" are not attempting to be a general purpose kernel that can be configured for any purpose.

At one time, Torvalds did try to use C++ for the kernel. There were too many places the language got in the way making it a most inefficient/bloated result. Not that it couldn't be done - it just wasn't efficient (https://lkml.org/lkml/2004/1/20/20).

And if I remember the kernel memory allocations, they are always in pages... so anything not a multiple of a page always wastes memory and causes memory fragmentation... which make using "new" and "delete" a poor choice.

Applications are in a different arena. They are not (or should not be) part of the kernel. This was just about C++ kernel modules.
I was referring to the non-support of C++. None of the supporting functions for C++ are there. No exceptions, no IO, no memory allocation that C++ can use.
different kernel, different use.

Linux is a general kernel for many uses - from the smallest controllers to the fastest mainframes. That requires the kernel code to be as portable as possible, and not make assumptions about what hardware capabilities exist. It will make use of them when they are available, but the software capabilities must be able to function even when the hardware may be "deficient" (for various definitions of deficient). As such, it is written to support all of them - and that requires the visibility of everything possible. Which means hidden memory allocations/deallocations is a big source of inefficiency.

In most platforms, the MMU can only handle a limited range of page sizes (most common used is 4K) - and anything other than page size wastes memory (both in unused space, and in excess page table management).

As per the following stack overflow article, C++ exceptions do not involve signals or the operating system. They simply run destructors, unwind the stack, and transfer control back to the nearest catch block. Thus, they should be suitable for kernel development, and if they had the blessing of the kernel would be a great way to propagate rich error information back to user applications. They could still be used without kernel involvement, but would need to be caught at module boundaries and translated into error codes. We do exactly this in our embedded C++ code.

http://stackoverflow.com/questions/4...me-implemented

Having looked at the assembly language produced by templates for embedded applications, I can say with certainty that they produce very fast, very tight code. The C++ template-based queues I authored for an embedded modem application ran circles around the equivalent built-in VxWorks containers that were authored in C.

At the Design West Embedded Systems Conference two years ago, expert C++ presenters were explaining why C++ templates can in many cases produce faster code than pure C, due to the compiler knowing more and being able to apply optimizations that a C compiler cannot safely apply. Having used C++ templates extensively in embedded applications, I can say from experience this is true.

C++ templates enable very flexible, reusable source code, while producing incredibly fast, lean & mean assembly. Kernel code would be faster and safer if templates were used instead of funky pointer manipulation based on member offsets within C structs for containers such as linked lists.

jpollard
what is so hard to understand on following facts

if you can do it with C you can do the same with C++
if you do not use certain C++ features you will not pay for it
there is nothing you can do with C that can not be done in the same way or better in C++
a C++ compiler will produce the same output for C code like a C compiler
100% compatible, that is a key feature of C++
even if you do not use a lot of features you have things like RAII and destructor guarantee or some use of templates (instead of macros)
what makes you programs more secure and efficient


not pay for what you do not use is a C++ fundamental.
and there is nothing hidden in C++, and you have full control for everything

technically, there are reasons for not use RTTI
or there might be reasons for not use exceptions,
or have special memory allocation/dealocation
this is all possible,

the same result or better (if used correct)
so there is technically no reason that C is required and C++ does not work.
there is not valid as reason why C++ can not be used in general for writing a kernel.
there is no valid reason that C++ would not produce the same or a better result than you could produce with C.

Very true, it is possible to change the file extension from '.c' to '.cc' and state that we have a program written in C++. Why would we do that though?

And what part of C++ that isn't supported doesn't work and hides the implementation from optimization do you miss?

Not using a feature is not the same as having the feature not available for unintended use. That allows for slopply coding.

Destructors (and constructors) explicitly cause kernel memory fragmentation. Hiding when and where they occur cause thrashing when not desired.

Exception handling is supposed to be an exception - it doesn't happen as a general course - doing that causes tons of cache misses, and causes a rather big performance penalty when they occur. And because the C++ compiler is creating them, you have no control over it.

If you avoid using the features of C++, then why use C++ at all?

There is nothing wrong with C++ for application use. Use it where it is suitable. But it is not that good at low level hardware control interaction where memory is limited, or has other hardware restrictions.

It has been tried. Some people do it anyway, but will not recognize the pitfalls being introduced.

I have yet to see a general purpose kernel written in C++. Have kernels been done in C++? sure. Are they in general use? nope. None of them.

ok, I see now that your opinion is immune again facts.

do you just want to troll around?

since the rest of your post has the same quality as the quoted part
I have to assume that you just want to argue for the sake of arguing.

I am sorry for trying to have a serious discussion with you

I do not want to do it.
I just state the opinion that if you do it
you have noting to lose because of the same resul.
and you can win if you use C++ features to improve where this is possible
so:
in the wort case you end up with the same result
in the best case with a better result

sounds like a good deal

Well-written C++ code is at least as compact and efficient as well-written C. Those who can do. Those who can't, write in C.

Overriding new and delete allows optimizing the memory allocation strategy for each type or category of object for the platform upon which the code is used. Clean, efficient, and readable.

So far as that antique Torvalds experiment goes, repeatedly quoting old and bad information does not make it either informative or correct.

The Linux community reaps what it sows with the "tainted" machinations and related licensing nonsense. The best drivers for high performance graphics cards will never be offered for Linux platforms.

And achieve the same as the well-written C++ code with less effort.
And slow. You now have two levels of memory allocations to fight with.
It also doesn't make it wrong. What was "bad information"?
That is totally up to the vendors that write drivers. Since they want to perform poorly, that is their choice.

That doesn't make sense to me. How does C++ "mangle" function names? In any case, I would have thought encapsulation would help avoid a lot of the bugs that would otherwise occur.

There is nothing to stop a kernel program from operating at the lowest level. At the very worst, you might need to modify the C header files:
#ifdef __cplusplus
extern "C" {
#endif
etc

http://en.wikipedia.org/wiki/Name_mangling

In compiler construction, name mangling (also called name decoration) is a technique used to solve various problems caused by the need to resolve unique names for programming entities in many modern programming languages.

That is to defeat the name mangling that C++ does.

There is no point to using C++ in the kernel if you have to avoid using C++ features.