OSDev.org

i wana ask why c language is mostly used in OS development.on the other hand c++ is object oriented language but still people don't prefer it for OS development.
can u please give me some comparison (with each other) of using c and c++ in OS development.

Actually, you'll find quite a few OS developers trying to use C++; however, most of those who try quickly find that it is more difficult than they anticipated, and many simply drop their C++ code and rewrite in C. Even those who use C++ in their OSes often stick to C for the kernel.

The main reason for this is because the advantages of C++ come at a price in memory size, speed, and most importantly, system overhead. Whereas most C code compiles into more or less straightforward assembly code, C++ has issues like overloaded function and variable names which complicate both code generation and code linking, especially when working with assembly code.

More critically, many features in C++ (RTTI, exception handling) require additional runtime support, in the form of additional, OS dependent code which the compiler has to add to the program. This overhead is large enough to seriously hamper using C++ for low-level code. While simply avoiding these features will get around the problem, it defeats the purpose of using C++ instead of C.

In order for C++ to maintain backwards compatibility with binaries, it must attend to the fragile base class problem. You can read about how BeOS engineers dealt with it here: http://2f.ru/holy-wars/fbc.html

I do not agree with Schol-R-Lea. The issues of runtime / system / memory overhead when using C++ are frequently overestimated. I have been working on the issue of using C++ in kernel space for some time now, and would really like to come up with some crisp examples, but my kernel being in the pathetic state it is, you will have to take my word for it.

IMHO, there are four things that make C++ second choice to C in OS development:

* Documentation. The vast majority of tutorials, how-tos and postings assume you are using C. C++ examples are few and far between.

* Complexity. Being the more complex language, C++ requires more "framework" than C. You have to set up more things (like, new(), exception support) before you can use the language to fullest effect. Papers on how to enable exceptions in kernel space are sparse.

* Experience. It is easier to screw up in C++ than in C. If you don't know what you are doing, your code can very easily turn out to be slow, memory inefficient, or downright buggy. Most OS developers are better at C than at C++.

* Predjudice. Look at the endless flamewars that appeared on the Linux kernel mailing list regarding the topic of C++ for kernel modules. I've read it all, in the early days of my project, for research purposes. Those are postings by kernel developers - and about 85-90% of what they claim makes C++ a bad choice for OS development is bullshit (sorry). This attitute festers. (No offense intended, but even Schol-R-Lea bought most of the urban legends!)

Add to this that C++ was standarized only "recently" (when compared with C), and that the C++ standard ABI is yet again younger. That standard ABI solved many of the problems surfacing during C++ kernel development, but it hasn't been around for long enough.

Bottom line: If you and your co-developers are C++ wizards (as in, years of experience with really hard-core code), by all means go ahead and try. It will be a rough road, and you'll do "firsts" in many areas, but it can be worth it.

Otherwise, don't bother. Go with the language you are most comfortable with - and seeing the abundance of C tutorials and how-tos, that'd be C.

Solar wrote:Look at the endless flamewars that appeared on the Linux kernel mailing list regarding the topic of C++ for kernel modules. I've read it all, in the early days of my project, for research purposes. Those are postings by kernel developers - and about 85-90% of what they claim makes C++ a bad choice for OS development is bullshit (sorry).

In the case of Linux, its a no-brainer: why bother with a C++ framework if it already exists in C? The Linux kernel is a lot of code, and rewriting it all "the C++ way" is impractical.

Which brings me to the next point.

The primary reason one would select C++ over C is to employ an object-oriented design methology. However, you don't get any advantage from an end-user viewpoint, and only some aesthetical benefit from a programmer standpoint (for OS design, anyway; GUIs are a different story). Other than that, there really isn't any compelling reason to use C++ when the kernel could be done in plain C just as well. C++ as a language is more complex, and hence will always incur a greater overhead than C. While it is arguable that such an overhead is minimized with the power of today's hardware, if you can eliminate such an overhead completely by avoiding C++, why not?

Summary: C is a bit simpler, faster, smaller, and much more mature language. If you cannot do without the additional features of C++, then by all means use C++. Otherwise, stick with C.

There's nothing to stop you from writing object-orientated code in C -- look at stdio.h for an example. In fact, that's how I write most of my C code anyway.

However, I agree with Solar in that the reasons against C++ in the kernel are few, and most of those are FUD stemming from the Linux kernel.

Personally I use C within the kernel itself, and in the OS libraries. However, I'm working on a FAT driver written in C++ -- Mobius file system drivers work equally well as C structs or C++ classes -- and the client-side GUI library consists of C++ classes. I find C++ particularly well suited to the GUI.

Solar wrote: I do not agree with Schol-R-Lea. The issues of runtime / system / memory overhead when using C++ are frequently overestimated.

I stand corrected. Thank you.

I would, however, add that the perception of these issues remains, and does explain why so few programmer stry to use C++, even if the reasons themselves are bogus. If even someone like myself, who is intending to write a kenrel in a language with a much higher minimum overhead than C++, could be confused on the issue, it is hardly surprising that others might be.

Schol-R-LEA wrote: I would, however, add that the perception of these issues remains, and does explain why so few programmer stry to use C++, even if the reasons themselves are bogus.

That is, very unfortunately, very true:

nullify wrote: In the case of Linux, its a no-brainer: why bother with a C++ framework if it already exists in C? The Linux kernel is a lot of code, and rewriting it all "the C++ way" is impractical.

Yes, that was one of the contra-C++ points fielded. However, no one to my knowledge ever suggested rewriting the kernel. Most of the flame threads started when someone suggested to cleanse the C kernel from C++ keywords, so that people could use C++ for writing kernel modules.

My personal favourite was the dude who used a quite complex shell command (including pipes and wc -l) to show how many code lines there are in the C kernel, and then continued to make a completely bogus calculation as to how many seconds per line it would take to scan the code for C++ keywords, coming up with a total of several man-years.

(Hint: He could have used a shell command using pipes and grep to find the C++ keywords directly...)

The primary reason one would select C++ over C is to employ an object-oriented design methology.

One, what's wrong in making a segment descriptor an object, and a descriptor table a container? After all, that's what they are, aren't they?

Two, if all I could use in kernel space were namespaces and references, I'd still mutter a silent prayer for getting rid of identifier uglification and pointers...

[you get] only some aesthetical benefit from a programmer standpoint (for OS design, anyway; GUIs are a different story).

I think it can make OS code much more readable, understandable, and maintainable, which is a very significant benefit IMHO.

C++ as a language is more complex, and hence will always incur a greater overhead than C.

Which is wrong, period.

Please, do not spread the urban legend of "C++ is always more overhead than C". I could easily dig up some examples where C++ algorithms beat C code by orders of magnitude (!), by design.

It depends on how you use the language.

While it is arguable that such an overhead is minimized with the power of today's hardware, if you can eliminate such an overhead completely by avoiding C++, why not?

For the same reason that people stopped coding kernels in pure Assembler.

Summary: C is a bit simpler, faster, smaller, and much more mature language.

I grant you "simpler" and "smaller", no discussion there. Faster? No. More mature? As in, "been around longer"? So is BCPL, and we no longer use that, either.

No offense intended, nullify, but that's the kind of subconscious reaction that is part of the problem why C++ is not often used.

If you cannot do without the additional features of C++, then by all means use C++. Otherwise, stick with C.

I could do very well without, but why should I? (Except for the lack of documentation, which I fully intend to address while I'm working on my kernel.)

Exceptions make for much cleaner error handling code if you know how to use them. (If not, you don't know C++ and should use a language you do know.)

A namespace kernel:: will allow me to keep identifiers clean and understandable. (I loathe POSIX style naming...)

Modern development environments will tell me at object. what I can do with an object of that type. (Intellisense)

It is more complex a runtime environment, it is poorly documented. C++ is more hostile if you don't know what you're doing. There is a strong predjudice against using C++, mostly out of ignorance / subconcious reflex.

But there is no technical reason why you shouldn't use C++.

couldn't agree with solar more on this one. I've been using C++ for my project OS for a little while now and I think in the long run I'll be able to write code which is far more clear and concise then if i were to write it in C.

for example, my semaphores simply work like this:
by the same token my "Interrupt Descriptor Table" is a container which has "Interrupt Descriptors" which i can fetch by index easy and update by a member function.

so long as you dont use many virtual functions C++ has same function calling overhead as C (an extra push for this pointer is negledgable). and once inside the functions, accessing members is no worse than accessing struct members.

also on the plus side, OOP lends itself to code reuse far more easily than other languages. For example, I have Mutex objects which are a special case Semaphore and I have Monitor objects which are semaphore based, all of which are very small classes).

now, I'm not saying that C or C++ is better, but there certainly is no real "technical" reason why not to use C++ (as Solar said), it's simply a matter of preference.

proxy

Solar wrote:My personal favourite was the dude who used a quite complex shell command (including pipes and wc -l) to show how many code lines there are in the C kernel, and then continued to make a completely bogus calculation as to how many seconds per line it would take to scan the code for C++ keywords, coming up with a total of several man-years.

(Hint: He could have used a shell command using pipes and grep to find the C++ keywords directly...)

The same dude also mentioned a very good point: "From past behaviour, the C++ standards people have not shown a commitment to 100% backwards compatibility. The fear is that C++ will continue to expand its claim on the namespace. This would generate an ongoing maintenance burden on the kernel developers."

Solar wrote: One, what's wrong in making a segment descriptor an object, and a descriptor table a container? After all, that's what they are, aren't they?

You _could_ implement it like that, or you could just make them structs and have functions act on that data (which is no less comprehendable). I personally prefer avoiding object-oriented design outside of certain areas of software development.

Solar wrote:Two, if all I could use in kernel space were namespaces and references, I'd still mutter a silent prayer for getting rid of identifier uglification and pointers...

This goes with what I said earlier: if you can't bear not having namespaces and references or any of the other C++-only features, then proceed in C++.

Solar wrote:

[you get] only some aesthetical benefit from a programmer standpoint (for OS design, anyway; GUIs are a different story).

I think it can make OS code much more readable, understandable, and maintainable, which is a very significant benefit IMHO.

Speaking from practical experience, I've actually found that maintaining, extending, and understanding OOP code vs. procedural code to be about the same, and sometimes OOP code even winds up requiring more time. The reason probably is due to OO nature of encapsulation. While encapsulation is sometimes the right way to do things, the inevitable side effect is that you end up writing more code to accomplish the same task "properly" in C++ than in pure C.

-------
My 3 responses above this are really quite subjective; they're more about the design methologies of C vs. C++ in general rather than specifically using either of them in the kernel.
------

Hmm, looks like this post is too long to fit in one. I have to split it up.

Please, do not spread the urban legend of "C++ is always more overhead than C". I could easily dig up some examples where C++ algorithms beat C code by orders of magnitude (!), by design.

It depends on how you use the language.

I'll have to take your word on this, because I have never seen an optimized C++ algorithm faster than the optimized C algorithm equivilant. But I must point out that "overhead" implies memory usage as well as execution speed. And you confirm that C++ has a bigger memory overhead than C later on.

Solar wrote:

While it is arguable that such an overhead is minimized with the power of today's hardware, if you can eliminate such an overhead completely by avoiding C++, why not?

For the same reason that people stopped coding kernels in pure Assembler.

The primary reason for the general switch from assembler to C was for the increased portability. I don't think you could argue that C++ code is much more portable than C code.

Solar wrote:I grant you "simpler" and "smaller", no discussion there. Faster? No. More mature? As in, "been around longer"? So is BCPL, and we no longer use that, either.

Once again, the "faster" issue I'll have to trust you on, because I haven't witnessed any evidence to change my opinion. About maturity: I mean "been around longer and _survived_". There is a key difference. The fact that C has been around for awhile and is still nearly ubiquous indicates that the language is flexible and general purpose enough to be a wise choice. I don't know much about BCPL, but the fact that it isn't really used anymore is probably a good indication that something is fundamentally wrong with it.

Solar wrote:No offense intended, nullify, but that's the kind of subconscious reaction that is part of the problem why C++ is not often used.

No offense taken, but I do think I've mentioned some things that are worthy of consideration before merely dismissing it as "FUD spread by Linux kernel people".

Solar wrote:

If you cannot do without the additional features of C++, then by all means use C++. Otherwise, stick with C.

I could do very well without, but why should I? (Except for the lack of documentation, which I fully intend to address while I'm working on my kernel.)

Exceptions make for much cleaner error handling code if you know how to use them. (If not, you don't know C++ and should use a language you do know.)

A namespace kernel:: will allow me to keep identifiers clean and understandable. (I loathe POSIX style naming...)

Modern development environments will tell me at object. what I can do with an object of that type. (Intellisense)

The first two features are examples of aesthetical advantages I wrote about earlier. I usually don't feel the need for exceptions and namespaces, because the issues they address haven't really been problematic for me. I'll admit that Intellisense is very nice, though.

Solar wrote:But there is no technical reason why you shouldn't use C++.

Some technical reasons are:
- C++ has a greater overhead (in terms of memory, at least)
- C++ requires you to implement additional language functionality that is system-specific in order for you to use it. Although you'll eventually need to code the same functionality in C anyway, the functionality is more central to C++ design ideals.
- Since C++ is a more complex language, C++ compilers are more likely to contain bugs, and C++ compiles are generally slower. This was a factor in the decision of Linux to stick with C back in the day. This is less of an issue today now that compiler technology has improved, but its something to bear in mind.
- C++ suffers from the fragile base class problem.

nullify wrote: And you confirm that C++ has a bigger memory overhead than C later on.

If you use one of the features that implies such overhead, yes. Those are features that C doesn't have. The question is, would you be able to create the same semantics, in C, without using up at least as much space?

Take exceptions. Yes, they take up memory. But, if you don't have exceptions, and handle error conditions the C way, would the additional error handling code (checking ERRNO upon return, setjmp / longjmp etc.) really be smaller?

As for the speed issue, I'll post an example later today.

BCPL is the ancestor of C. It was superseded because C was considered more practical. Now, I don't say that C++ could or should supersede C, but it is an advancement.

What was said about the C++ committee... Yes, they extended the standard over time, as new issues arose. At times, that required adding another keyword, making some identifiers illegal. So what? We are talking about one global search & replace here! BTW, C99 isn't fully compatible to K&R C, either...

Then, the fragile base class problem... that is an issue for C++ interfaces, i.e. when you export a C++ API through syscalls. That's a whole different decision from writing a kernel in C++. I'm not even sure if that problem still persists now that the standard C++ ABI is around. (Hadn't had the time to check this yet.)

Then, the aesthetics... well, that's personal preference, and certainly not a technical reason one way or another.

Portability... well, really fine C++ code is more portable than C code, in the sense of modularity. But that would be going too far. But one other reason to use C over Assembler is readability, maintainability, abstraction. And especially on the abstraction level C++ beats C hands-down.

But this is, basically, bickering. You say that, if someone can't live without C++, he should go for it. I say that, if some can do C++, he should go for it. That's probably because I can do, and you can do without, but in the end, we basically agree.

Regarding efficiency. It's not really an example, and I won't elaborate on the technical details, but...

Scott Meyers, "Effective STL", p. 203

The fact that function pointer parameters inhibit inlining explains an observation that long-time C programmers often find hard to believe: C++'s sort virtually always embarrasses C's qsort when it comes to speed. Sure, C++ has function and class templates to instantiate and funny-looking operator() functions to invoke while C makes a simple function call, but all that C++ "overhead" is absorbed during compilation. At runtime, sort makes inline calls to its comparison function (assuming the comparison function has been declared inline and its body is available during compilation) while qsort calls its comparison function through a pointer. The end result is that sort runs faster. In my tests on a vector of a million doubles, it ran up to 670% faster, but don't take my word for it, try it yourself. It's easy to verify that when comparing function objects and real functions as algorithm parameters, there's an abstraction bonus.

Add to this that the so-called "memory overhead" of C++ usually boils down to one vtable per class and one pointer per object.

Are vtables required in non-virtual classes?

No.