I read something somewhere (sorry, I can't remember) about being able to write C++ code and turn it into an operating system. Am I right, or is the page wrong / I misinterpreted it?

I know a little C++ and, assuming that I am right, would like to give it a try.

Not sure how code can be turned into an OS, but one example of a C++-based OS is Symbian. BeOS also seems to contain a lot of C++, and while Apple's OSs don't use C++, they use Objective-C.

1 members found this post helpful.

Haiku uses c++ too

It is possible to write almost an entire operating system in c++, but not quite. The parts that are not possible to write in c++ can be written in c, and the remainder is standard assembler code. But is it wise to write an entire operating system in c++? NO, because it's too slow! C takes more time to write, but it's faster running. Someone wrote an entire os in assembler. It has a full GUI and several applications, and the entire thing is around 4.0 MB. That's extreme, but c++ is the other extreme except for maybe java.

4 members found this post helpful.

Nonsense. Any part you could write in c, you could write in c++. In most cases the source could be identical in c++ as it might be in c. In rare cases where an exact match of c source code would not mean the right thing in c++ there is alternate c++ syntax that matches the meaning of the c.

At least a tiny bit of an OS must be in assembler. Embedded asm is part of gcc in either c or c++, so you don't need any "standard" assembler, just the gcc extension to c or c++ that lets you include embedded asm.

Wrong again. Any good c++ programmer can avoid all the performance pitfalls of c++ and write c++ code that has better structure and maintainability than you could achieve in c, while not losing any performance relative to c.

C++ has a lot of potential to trick a beginner into thinking some construct is simple, when that construct really includes a serious performance flaw. So beginner code in C++ is likely to be slower than C code written by a similar beginner. The same is not true with good programmers. In complex problems, a C programmer often needs to compromise performance in order to write and maintain a manageable amount of source code, where a C++ programmer can use templates to get the best possible performance, while keeping the source code size manageable (and only the binary size explodes).

2 members found this post helpful.

You CAN write a kernel in C++...

But only by eliminating most of the C++ features (and templates do NOT give the "best possible performance" - they do give better PROGRAMMER performance though). The problem is that C++ has to have a certain amount of runtime support - even minor exception handling cannot be used, no object references (requires memory allocation/deallocation). The problem is cause by the runtime support... it is nearly a kernel in its own right, and not implemented in C++ (at least the last one I looked at wasn't - it was written in C). Thus you get into a recursive problem... This is the same problem that Ada has. Good for implementing applications.. bad for implementing systems (actually, Ada is worse, as there is no subset of Ada that can avoid using the runtime).

Once you are outside the kernel (the majority of the OS), C++ is not a problem unless you are limited in memory (such as device controllers).

I disagree.

C++ exception handling (even a little) may be too expensive for an OS. So it may be a C++ feature than someone writing an OS in C++ decides not to use.

You are either completely wrong or using incorrect terminology to express I can't guess what. What you seem to be saying is just wrong.

Inside an OS kernel C++ is not a problem, in fact it would be the best language.

Many of the templates I have coded do give the best possible performance. Sometimes I can beat C++ by coding in asm, but it is almost never worth the effort and most asm programmers can't do it anyway, even with all the effort.

If you look at situations where a good C++ programmer would use templates for performance, you will consistently see that good C programmers use function pointers and other less efficient constructs getting code that is slightly less run time efficient and slightly less maintainable than the C++ version. Obviously you could write a massive amount of C code to duplicate the performance of the C++ code, but no one does it that way.

my opinion is that c is more efficient than c++:in this small unscientific test it shows that the
- c++ compiled output is larger than the c version.
- generated assembly instructions from c++ are about 4 times longer than the c version.
- c++ example takes 33% longer than the c example to run hello world 1,000 times.

i think this has to do with how c++ is much more object oriented than c which is easier for programmers but not so easy for computers. kinda' like how java is fully object oriented and android suffers from lag (less noticeable on fones/tablets with quad-core cpus).

And yet, no one uses C++ for a kernel. Several have tried, but none of them are currently in use.

Not even Microsoft, though they did try.

Even Linus gave it a shot... Too much overhead required.

The problem here is that you have to include the overhead for C++ construction for stdout. If you drop that and go directly to the system call (using write) it is close to the same size as the C version.

This has always been one of the claims for "bloated" for C++ applications. The language makes some things much easier to do - but the overhead makes using them not trivial.

The problem Java has is that the language itself is bloated. The interpreter used has to implement the full instance activations... It can be close to machine speed because the more the interpreter takes over from the language, the faster the AVERAGE throughput becomes. But it still has an interpreters overhead added.

Forgot to add, the interpreters overhead added to the object support runtime overhead.

You should look here: http://wiki.osdev.org/Expanded_Main_Page

There's a wealth of information about writing OS stuff here. If there's any compulsive programmers out there who don't need a new project, attempt to avert your attention.

I remember quite a long time ago taking an OS course while getting my masters degree in computer science. As part of the course we had to write our own (small -- I remember mine being ca 10K lines of code) kernel that ran on simulated SPARC hardware (this was before virtualization in the PC space got really big). The professor told us that although it was possible to write an OS in C++, almost nobody has ever successfully done so. The reason is that because when writing a kernel, you have absolutely no external library support. You cannt use the standard C or C++ libraries (no STL), unless you implement them yourself within the kernel. Library loading is a function handled by the OS, and if you're the one writing the OS, you handle all of the gory details of how that is done yourself. If your kernel is highly dependent on these features, you might even have to figure out how to have these features available before you've done things liek set up virtual memory or have the root filesystem (or its moral equivalent) available.

Without access to the STL and exceptions, you lose a lot of what makes C++ convenient for the programming. Also, the way that name mangling works with the class/method structure can make the kernel symbol table a bit problematic (since the names of symbols are not actually the names you give them). I've always felt the latter problem could be solved if someone put enough thought into it, though.

The long and short of it is there are enough issues that restrict access to C++ features that msoe kernel developers conclude it's just as easy to go back to C. Contrary to popular belief, it is possible to do OO programming in straight C, although its syntactically pretty ugly. Look at the VFS layer for an example of where some OO features are implemented in the Linux kernel.

Also, on the x86 architecture, there are a few things that simply must be done in assembly. Switching the CPU from real to protected mode comes to mind, but there are others actions invovled in context switching between processes, IIRC.

2 members found this post helpful.

I guess software "experts" who have never done asm debugging of C++ code tend to have no clue of what is actually going on under the hood.

Most of STL is templates (hence the name) that are fully compiled into your code at compile time. The use of run time libraries for parts of STL is a minor convenience detail that you can easily avoid without re implementing any of STL.

A lot of STL ends up calling memory allocation (in most implementations reaching malloc). If you are coding an OS kernel in C++ or in C, you pretty much need to provide your own implementation of malloc. A malloc designed for use in a process running under an OS is not usable for the OS's own memory allocation.

Depending on your definition of "successfully", almost no one has successfully written an OS in any language. That doesn't mean C++ is a bad language for writing an OS. I wrote a few (successful) OS's long ago when hardware and OS's were simpler. It is far harder to write a real OS no, but no specific detail of an OS is harder now than then, there are just a lot more details to cover. While I didn't write any OS in C++, I know enough about OS internals as well as enough about C++ internals to know there is no problem with C++ for writing an OS.

Big projects, like Linux and GCC, implemented in C, tend to reinvent many of the features of C++ as kludgy macros with ugly syntax and nasty restrictions. That makes those projects hard to maintain even for experienced maintainers and very hard to enter for outside programmers. Having such features built-in consistently makes C++ a better language. Project political inertia keeps big projects from switching.

an apples to fruit salad comparison that is unfair in any context in which it might mean anything, but especially unfair regarding kernel development.

Try implimenting a general purpose priority queue algorithm (using a heap) in C and (also in C) applying that algorithm to several different queues of different kinds of polymorphic (within some of the queues) data structures. Now do the same in C++ and compare execution speed. It isn't just easier to code in C++, the result will also execute faster. For someone at my level of programming, implimenting the priority queue templates in C++ is easy enough that fitting the project requirements even a tiny bit better than the STL priority queue is worth rewriting it. The STL one beats what you might do in C, but I can (and in several projects have) beat that. Another programmer writing a kernel in C++ might just use the STL priority queue. It is better than you would be likely to do yourself in C. An OS kernel needs several priority queues and it is a place performance can really matter.

I've developed similar things in C and in C++. The C thing always compile fastest. And that diffeence could add a significant amount of time to the debugging of something complicated. Less of an issue these days with faster I/O and multiple cores, but still something to consider if you have to build large things for multiple architectures. Like a linux kernel.

@johnsfine: The professor of my OS course had many years of real-world software development experience, including OS development and launching open source projects to allow Python to talk to compiled languages such as C++ and Fortran. On the whole, I'm a bit more likely to trust him than some guy on an Internet forum :-D. Don't be so dismissive of "experts", just because you don't happen to like the conclusions they've drawn. At the same time, it's a mistake to put too much trust in them, since even experts have their biases.

I've never particularly liked C++, and I'll admit some of this is inherent bias that's not particularly fair. I've been meaning to dive back into my Stroustrup text and try to get-familiar with it. I have no doubt than at OS can be written in C++, however it's a much harder challenge than writing one in C, especially depending on what language features are to be used (I imagine exception handling in kernel mode could get quite ugly). You're not going to be able to use "new" and "delete" (as is statesdabove), so you're going to have to provide your own way of doing this. At this point, what does C++ give you, besides templates and classes? I'm honestly curious (like I said, I'm not a C++ gurur by any stretch of the imagination). What specific features would it have that would make it a better choice than C, given the limitations and/or extra work needed to support its runtime environment?