Not to beat this to death, but I most certainly would use new and delete if writing a kernel in C++.

I might (or might not) overload those operators to get more efficient access to something like a slab allocator. But with or without overloading new and delete for some performance critical objects, I would have new and delete default to passing their allocation work onto malloc. As I said above, one would write a replacement for malloc when writing a kernel. But most of the C++ value of new/delete is still in place after you replace malloc.

There are simple right and wrong aspects to this, not matters of opinion. If you don't have that knowledge yourself, I understand you have no reason to trust me rather than some professor. But don't tell me I don't happen to like their conclusions. From my perspective, these are questions of simple fact, neither complicated nor based on opinion (how object references work, how STL works, etc.)

The real question is whether or not it's a good idea to write a kernel in C++. This is a metter of opinion. The facts of how C++ works are not in dispute here; what is in dispute is whether the language feature of C++ make it a good choice for OS development. My contention is that, for a novice OS developer, C++ adds substanital complexity and is probably not the best language choice to learn about OS development.

Interesting discussion, though.

The problem is that memory allocation in the kernel does not work like malloc... Using it that way causes a LOT of wasted memory due to various allocation limitations- like page size limits. Minimum allocation is a page - so how big is a page? Depending on hardware, that minimum might be 1MB, or 4K and it might even differ depending on WHERE in the kernel things are being done. Unless using layered allocations... (which gets more complex- they are not necessarily contiguous sections). What works in one place will not necessarily work in another. Hence there are multiple DIFFERENT memory allocation methods used.
Most kernels are dynamic... they add modules/remove modules on the fly. C++ doesn't like it when things disappear - unless you go to using pointer tables... In which case you aren't using C++ anymore.

Now for a static kernel, without on-the-fly reconfiguration, C++ might work just fine. The results might be a bit bloated, but it will work - just don't expect portability without also having to recompile for each platform, even if using the same CPU. Once you start dynamically loading modules you get out of the C++ environment and back into the low level coding that is the foundation of C.

C was DESIGNED for such low level coding as this. C++ was designed for applications. That it COULD be used for low level coding is a bonus... but when doing such low level coding the advanced language features just get in the way.

Having worked as an embedded software engineer for a long time: Here's what will happen in the real world.

1) If you write an OS in C++, and its a competitive product, your competitor will have many opportunities to write the same thing in C and make their product faster and smaller. Thus putting your product at risk.

2) If you write an OS in C++ as an employee for a company: At crunch time (memory+performance), another engineer will start rewriting your C++ code as C and the C++ code will be resigned to a old node in a CM system.

This can happen with C compared to ASM, but C can be written to be competitive with ASM in many cases without too much fuss.

So yes, you may be able to do it but the rewards/risk doesn't side with C++ - as proven by commercial OSs on the market today.

In addition, if the OS is for an embedded application, the choice of the micro controller is a cost factor of the product and is also a variable from product conception to proto. Many times the micro is switched to a different size/brand during development and the code has to be rewritten - sometimes to ASM if the micro is bleeding edge. There's a lag time from new micro until a compiler is available for it and the first compiler will always be a C compiler, not C++. Going from C to ASM and from ASM to C is a straight forward process. If you have written your code in C++ you're screwed - You'll have to re-design your code instead of just converting from one language to another.

My $.02

1 members found this post helpful.

Thanks for all the input!

So it sounds like an OS in C++ not going to be something I would be able to do. I'm just a kid in high school and thought it would be interesting to try to write a "Hello, World!" OS over Christmas break, with maybe a few inputs and outputs.

I'll look into this, thanks.

Again, thank you everyone for the response!

I don't doubt you but do you have an example ?

Different priority queues? no problem.

Task scheduling is one.
IO scheduling is another(buffer ordering).
And then there is process scheduling.
Real time scheduling.
interrupt scheduling.

None of these share the same data structure, yet all are scheduling features.

I don't have an example of a generic C++ priority scheduling algorithm that could be used for all four. They work totally differently.

Yes, you could write an OS in C++ (although parts might have to be in assembler).

If all you want to do is make the character string "Hello, world" appear on the screen, it's not that hard and can be done with a little bit of basic C with a little inline assembler to write directly into video memory. Look at some of the basic bootloader examples on the OSDEV wiki, and you'll quickly see how it's done.

If you want to do more than this, you'll need to get into some fairly in-depth C (or C++) and assembler work, as well as learning more than you ever really wanted to know about how hacky the x86 architecture really is (you'll get to become good friends with the A20 line, for instance).

I followed the link that MYK267 posted, and realized that most of this is way over my head. Maybe I'll come back to it when I graduate from high school.

Thanks for your time!

The fun part was the C++ entry... "To write a kernel in C++, simply use the code above (which also happens to be legal C++) and save it in a kernel.cp (or what your favorite C++ filename extension is)."

And I had forgotten about the C++ name mangling causing problems.