C is more efficient than C++
You can do C++ code as efficient as C code, but you have to take much care, because much processing is hidden when you use C++.
The kernel talks to the hardware directly and C is the best language for that.
You could try java, but the result would be an Os that need a JVM to run and another OS to run the JVM.
You could try awk, but the OS would only be able to parse big text files and wuoldn't be that useful.
You could try spanish, but the processor would not understand the OS.
Believe me, I've tryed to write OSes in many languages and C is the most reasonable solution.

HI
as Agrouf said C++ and other OO languages have many hidden processing, because they have inheritance and polymorphism which increase CPU overheads. although the efficiency of the code depends on programmer but generally C language is much efficient..

Because C++ was too boring to code and probably didn't existed when AT&T guys decided to code Unix.

But the question was about the Linux kernel, not Unix. AND, when Unix was first written, there was no C.

AND----coding in C is not boring?

apologies, my oversight.Agreed Unix was not first written in C but then later the entire OS was re-written in C.

At least its better than C++ and assembly language.

It's simple, really simple: you code, you decide. You don't code: you don't complain (at least, not until you make a port using your favourite language :P ).

Each programmer has his/her own tastes, and each language is better suited for a particular task. When you are talking about low level tasks, OO programming is not going to do you particularly any good at all. It wouldn't even be faster to code (which is one of the things why I prefer C++ to C for graphic interfaces) because an OO language is not a natural thing for a low level task.

On another matter, I don't think asm would be any better for such a big thing, instead it would just make out for a very low quality product, or, at most, a product that could only be run on x86. Linux, on the contrary, being written in C for the most part, can be run on a wide range of architectures. That's a big advantage of C as well.

C is a good language, like it or not. And it's particularly good for this task. As a bonus, it's easy to find good C programmers with a wide experience, which is a guarantee that, when you eventually leave or you can't continue with your project alone, you will find enough human force to continue the work for or with you.

C is best suited for developing an OS because it's powerful and efficient to access low level hardware like registers.

OO is a way to resolve problems. It's a method, not a language. If you take a look at Linux kernel code (and BSD kernel code), you will see that OO method is used in VM, VFS, ...etc. If C can bring the benefits of OO on the table, why bother to introduce overhead built in other OO-featured languages, for example, C++?

Question*: Did Linus have a C++ compiler? Also I know that at the time Linux was an overblown rsh reimplementation that was really just made so that he could better understand assembler on the 386.

*That was not rhetorical.

That's besides the point in any case. Maybe he did not even know C++. Which is also besides the point.

No programmer can own a compiler for every language, and no programmer can know every single language over the sun.

So, each programmer chooses the tools s/he thinks it's the best for the purpose, amongst these that are available to him (in both senses of owning a compiler and having the knowledge about it).

As I said (and the license permits it) no one is stopping you or anyone else from porting it to any other language, if you feel brave enough. So far, no one has ever thought about that, probably because there's absolutely no benefit in doing it (in my humble opinion, that's it).

Now, that is a valid question. As far as I can tell it just makes things 3-4 times larger than they need to be and harder to read.

I really don't see what advantages it brings over stanza based or field delimited files.

The T-Rex

http://www.livescience.com/animals/0...o_tissues.html


The the first compiler was made either in hex or with binary...lol

There are some good things about XML.
Some people use it where they shouldn't, but it has some advantages.
It can be hand written and translated easily. Also, there are many tools for validating and for parsing XML. And it can be described with DTD or XSD, enforcing some logical rules that prevent misuse of the XML. Also, it is extensible, so you don't have to reinvent the world when you want to decline your own format, and you can use subset of another format, like it is done for SVG.
It is important to have a good standard because applications are more and more interconnected. For instance, you can put some svg imported from inkscape inside open office document and keep the format simple.
You can make your own format but usually it is not a good idea because you forget a lot of things.
For simple things, a simple key-value pair file is usually sufficient, but when things become complicated, XML is a good choice.
For very large data, binary is better but it requires more work.
The good balance for medium-sized data is to use zipped XML, like SVGZ.

"An operating-system kernel," which creates the warm and fuzzy environment that every application-program has come to expect, actually has to live in a much more complicated environment: "the actual hardware."

In this environment, speed is sometimes critically-important. Being able to know exactly what will happen when a particular piece of code runs, and exactly what set of machine-instructions will be produced, is sometimes essential. This is the major reason why different coding-strategies are used.

Languages like C++ strive to produce an environment in which application development is easy and in which the resulting applications can run reliably. The so-called "runtime environment" provided by such languages (and upon which all programs written in the language utterly depend...) is rich and powerful. In so-called user-land, such attributes are highly desirable. But kernel-land neither requires them nor particularly benefits from them.

"The kernel," critical though it may be, is actually a very small part of the operational software that makes up a computer system. In fact, efforts are constantly being made to make it smaller: to move "more stuff" into user-land. The kernel is the foundation: the building is built on top of it, and when all is said and done, "the building is really what's important." We can afford to use different coding-practices when building the kernel.