Kernel Developement in C++

[kan]

hi,
Is it a good idea to develop Kernel entirely in C++? Why is it that most OS developers run away from C++ for kernel dev?
What i think is that since C++ is a Object Oriented Language, its the best choice for OS developement! We can think of each hardware device as a object, for eg: harddisk can be treated as a object, keyboard,mouse etc.
And even GUI developement would be great in C++!
Ofcourse some nominal use of assembly is assumed! But point here is to use C++ instead of C.

Is just the extra coding required for C++ for runtime support & global objects etc hampering its use for Kernel dev?

Well somebody plz suggest me some matter , links for developing Kernel in C++. Very small amount of matter is available on net for the same. And even for adding runtime support etc.

[carbonBased]

I think you're exactly right... a lot of developers fear the effort required to get a decent C++ runtime library up and running. Some people seem to think it's more effort then it's worth.

Personally, I'd disagree. With written OSs in both C and C++ and each have their advantage.

You can still write object oriented code in C, of course, but not quite in the same way. C also performs no name mangling and a lot of ppl understand it better.

C++ allows much more interesting language constructs, and (of course) OOP as it was (more-or-less) intended.

You might want to take a look at the Trion project for an idea on how to start writting a kernel in C++.

Cheers,
Jeff

[neil]

And even GUI developement would be great in C++!

You have to do GUI using an object-oriented language (or at least object emulation in C for example) look for example at QT (C++) or GTK (written in C, but with many POO concepts (classes, objects, extension, ...).

L4Ka is a (very efficient) new generation micro-kernel written in C++ (and assembly of course). You might have a look at http://l4ka.org/.

[__matt__]

You have to do GUI using an object-oriented language (or at least object emulation in C for example) look for example at QT (C++) or GTK (written in C, but with many POO concepts (classes, objects, extension, ...).

Object-oriented programming has very little to do with specific languages; for instance, I think it's possible to do OOP in BASIC. (A total pain, prehaps, but possible!) A lot of the stuff I do in C could be considered object-oriented, and it's probably cleaner and faster than the equivalent C++ would be. I've never needed inheritance, so I've been able to avoid all the code (my own code and the compiler's generated code) that goes with it.

GUIs don't necessarily have anything to do with OOP, either. I've written GUIs for games and various projects that don't use any OO features like classes or inheritance. So, I don't think GUIs *need* to be implemented with OOP.

Personally, I try to avoid the term "object oriented" to begin with, because it's misleading and confuses people... even smart people who should know better.

With written OSs in both C and C++ and each have their advantage.

You can still write object oriented code in C, of course, but not quite in the same way. C also performs no name mangling and a lot of ppl understand it better.

C++ allows much more interesting language constructs, and (of course) OOP as it was (more-or-less) intended.

I basically agree with all of this; however, more experienced hackers think that using C++ in a kernel is probably a bad idea. This very issue has been debated several times on the linux-kernel mailing list. Every time someone drags it back into the discussion, it gets shot down: the lead developers believe that C++'s generated code and runtime support is too big, too slow and too flaky for a piece of software as stability- and performance-critical as the kernel.

What i think is that since C++ is a Object Oriented Language, its the best choice for OS developement! We can think of each hardware device as a object, for eg: harddisk can be treated as a object, keyboard,mouse etc.

As I explained above, you don't need a so-called "object-oriented" language to do OOP.

Yes, the various parts of a computer can all be considered to be objects... but what's the value of that abstraction? There's not much point in turning everything into a universal "object". What properties will all objects have... shape, size, mass? Those aren't useful to us while we're trying to write operating systems.

Instead, we try to find meaningful, useful abstractions. For instance, in the Unix world, many things are abstracted as "files" -- byte streams. If we can write an OS that "considers" as many things as possible to be byte streams (byte sources, byte sinks or pipes), then we can connect our abstracted components together in lots of useful and interesting ways: echo keyboard input to screen, stream data from disk to network socket, et cetera.

Henery Spencer said, "Those who do not understand Unix are condemned to reinvent it, poorly." Heed these words. Some people don't like Unix, but it's survived for 30 years and is still very popular. On the technical side of things, some versions of Unix (like Linux and QNX) are beating the crap out of nearly every other OS out there. So, instead of trying to come up with something "cool" or "original" or "object-oriented" or "better than Unix", try to learn from Unix's successes (and mistakes), and implement what you learn in your OS projects.

And even GUI developement would be great in C++!

Read my reply to Neil above. You don't have to write GUIs in C++; you don't have to write them using OOP either.

Further, doing a GUI directly in your kernel is a bad thing. Windows NT is an example; the GUI was integrated into the kernel, but this made the kernel very unstable, and opened up a ton of security holes. It's probably better to write your kernel first, and then implementing a GUI in userspace. For and example, check out the X Window System.

But point here is to use C++ instead of C.

Why? Do you have a specific need or reason to use C++? Please read my replies above; there are considerable disadvantages with few (if any) advantages to using C++ instead of C.

[trey_monty]

I dont at the moment want to develop a full os i need to download a small one in which to build off of.

[__matt__]

I dont at the moment want to develop a full os i need to download a small one in which to build off of.

What you need depends on what OS you're building from/within. (You must already have an OS on your computer, or else you wouldn't have been able to post that message...). If you're running some version of Windows, you can try Mingw or DJGPP; both of these simulate a Unix environment in Windows. (The native Windows programming environment is gross; avoid it if you can.) I don't use Mingw, so I don't know where to get it; I'm sure someone else here does, so they can point you in the right direction with Mingw.

When I'm programming in Windows, I use DJGPP (DJ Delorie's collection of Unix tools ported to DOS on the PC). DJGPP includes a port of GCC (the GNU Compiler Collection -- C/C++ compilers), make (a semi-automated build tool), the GNU binutils (an assembler and linker) and some other handy utilities. You can find more info and can download DJGPP packages from http://www.delorie.com/ .

If you're running Linux, you probably already have everything you need. Most Linux distros include GCC, binutils, make, etc so you won't need to download anything.

[Legend]

You have to do GUI using an object-oriented language (or at least object emulation in C for example) look for example at QT (C++) or GTK (written in C, but with many POO concepts (classes, objects, extension, ...).

Object-oriented programming has very little to do with specific languages; for instance, I think it's possible to do OOP in BASIC. (A total pain, prehaps, but possible!) A lot of the stuff I do in C could be considered object-oriented, and it's probably cleaner and faster than the equivalent C++ would be. I've never needed inheritance, so I've been able to avoid all the code (my own code and the compiler's generated code) that goes with it.

Cleaner? Depends, multiple inheritance in C++ is evil, but faster? Doubt this, most who claim to have a slow down with C++ then come with clumsy solutions in C (like with function pointers instead of virtual functions) which are not any faster at all, more likely slower.

And why recode everything yourself when there are more then one language to support you in OOP?

Most arguments from the linux kernel guys are from gcc 2.95 and before times, where the g++ sucked.

[__matt__]

Cleaner? Depends...

I was referring to the assembly code that the compilers generate, not necessarily the source code (although I personally find C++ source code to be a bit gross and harder to read than C). Even when your code only uses the "C subset" of C++, most C++ compilers generate more code, and generate slower code, than C compilers will.

Multiple inheritance in C++ is evil, but faster? Doubt this, most who claim to have a slow down with C++ then come with clumsy solutions in C (like with function pointers instead of virtual functions) which are not any faster at all, more likely slower.

In theory, C++ compilers will output "fast" or "optimized" assembly if your code only uses C features (no classes, no inheritance, etc). In practice, the compiled code is usually worse (larger and/or slower) than the compiled C code. The difference is in C's favor, not the other way around.

I think you're mistaken about function pointers; they are very simple and fast. On most architectures, a function pointer invocation gets compiled into a mov instruction and a call/jump instruction (plus any movs to get function arguments on the stack -- this is not specific to function pointers). On the other hand, calling a method involves (possibly multiple) virtual method table lookups; the end result may be the same, but the C++ code does a bunch of extra work to get there.

And why recode everything yourself when there are more then one language to support you in OOP?

Huh? What do you mean by "recode"? If you're referring to code reuse... that has nothing to do with language choice. There are tons of reusable code floating around the Internet for almost every language. For instance, if you wanted to write an OS you could use the Flux OSKit library (which is written in C).

Most arguments from the linux kernel guys are from gcc 2.95 and before times, where the g++ sucked.

That was true then, and (to some extent) it will always be true, because of the extra overhead that I mentioned above. If you don't believe me, then post something on linux-kernel about using C++ in the kernel. If you can come up with working code that is faster, smaller and more stable as the existing working C code, the kernel developers might pay attention. Otherwise, you'll probably be ignored.

[__matt__]

My opinion of language choice for kernels is this:

Some parts of your kernel *must* be written in assembly, because you can't specify low-level stuff like protection mode switches, paging management and stack/threading junk from a high-level language. So don't complain, don't try to avoid assembly; just do it. However, don't take this too far; try to write as little assembly as possible, because assembly is hard to debug and maintain.

The rest of your kernel should be written in C. All the current production OSes (Linux, proprietary Unixes, Windows, MacOS X) are written in C. C (the language itself and the generated assembly) is smaller, faster and generally simpler than C++ or Pascal or any other high-level language. On top of that, C was created to write an OS! On the other hand, Pascal was created as a teaching tool. C's logic, semantics and syntax are simple enough that you can fit the entire language in your head. Bjarne Stroustrup (the creator of C++) said that C++ was so big, he didn't expect people to bother to learn the whole language, much less remember and use it all.

Resistance is futile.

[Legend]

I think you're mistaken about function pointers; they are very simple and fast. On most architectures, a function pointer invocation gets compiled into a mov instruction and a call/jump instruction (plus any movs to get function arguments on the stack -- this is not specific to function pointers). On the other hand, calling a method involves (possibly multiple) virtual method table lookups; the end result may be the same, but the C++ code does a bunch of extra work to get there.

A mov, and a call, after you have calced the address of the pointer in any structure that you might use, which you have forgotten. If you use global function pointer vars, then it might be a bit faster, but then you are damn inflexible, too.

And why recode everything yourself when there are more then one language to support you in OOP?

Huh? What do you mean by "recode"? If you're referring to code reuse... that has nothing to do with language choice. There are tons of reusable code floating around the Internet for almost every language. For instance, if you wanted to write an OS you could use the Flux OSKit library (which is written in C).

The virtual functions would be an example here. I meant for example managing pointers yourself in that case. There some small things, that could be added. (malloc + constructor call instead of new, etc.)

Most arguments from the linux kernel guys are from gcc 2.95 and before times, where the g++ sucked.

That was true then, and (to some extent) it will always be true, because of the extra overhead that I mentioned above. If you don't believe me, then post something on linux-kernel about using C++ in the kernel. If you can come up with working code that is faster, smaller and more stable as the existing working C code, the kernel developers might pay attention. Otherwise, you'll probably be ignored.

I know some discussions on the kernel mailing list, and that place is the last one to try any real improvement. Even if you would have faster, smaller and more stable code in C++, you will be ignored and flamed to death there.

[baileyde5]

All interested in this topic may find this article from Microsoft on the topic of C vs C++ for kernel code informative:

http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

[carbonBased]

I basically agree with all of this; however, more experienced hackers think that using C++ in a kernel is probably a bad idea. This very issue has been debated several times on the linux-kernel mailing list. Every time someone drags it back into the discussion, it gets shot down: the lead developers believe that C++'s generated code and runtime support is too big, too slow and too flaky for a piece of software as stability- and performance-critical as the kernel.

I wouldn't imply those that've written a C++ kernel "unexperienced." The fact that it's debated suggests there are experienced people on both sides of the fence. And implementing C++ on a kernel that's already entirely C (disregarding assembly) isn't a fair comparison.

C++ (in particular the GNU C++ compiler suite) has come a long way, and I (umong many others) consider it on a par with C for all the critisicm mentioned above... and I've written apps to test and prove that it's more then adequate for all I use it for.

In particular, I've known several projects that decided upon C, and ended up implementing their own OO layer ontop of C which ended up causing more problems and bugs then would've existed if they would've just used C++ (or another object oriented language) in the first place.

And, of course, there's precedence for great OSs made with OO languages (BeOS/C++ and NeXTSTEP/Objective-C to name the most popular).

My two cents -- point being, if anyone's considering writting an OS in C++, I wouldn't get discouraged with all this. You can do some pretty amazing things with C++ in an OS.

Cheers,
Jeff