The Reliability and Necessity of C++ for OS Kernels

[Perica]

..

[Schol-R-LEA]

I would say that the real questions come down to:

IF the data structures you are using are complex enough that they would they benefit from the greater abstraction of the C++ object model; and
IF there were no other way of getting those advantages without using C++; and,
IF the benefits outweigh the greater implementation time, complexity and runtime overhead required to support C++; and
IF you feel as comfortable or more so using C++ rather than C;

OR

IF the effort of rewriting in C what you have already done in C++ would be more than the effort of getting C++ working and stable;

...then you would want to use C++ as your implementation language. Otherwise, it isn't worth it, probably.

Mind you, the language I mean to use has even more runtime overhead, but that's a personal choice, and one I may come to regret over time.

[Pype.Clicker]

Both C and C++ have interresting features and drawbacks for OS development. Imho, C++ is far too complicated in its design ('friendship' vs java packages, for instance ... or multiple inheritance vs java interfaces ...)

I don't think all those "operator overloading" stuffs can be really useful for OS dev, except maybe for a "callback" object that could abstract cross-segment calls.

I'm still waiting for a C-like language where i could define the appropriate behaviour of blocks like "synchronized(object) { ... }", etc.

[Perica]

..

[whyme_t]

It depends on your motivations for creating an OS. I'm just writing a Kernel to gain understanding of the internals and structures. My real interest would be networking, but net support in my kernel is far away.

I've stopped my Kernel development for the mean time, because I want to step back and actually design everything, rather than just hack as I go along. Here is an earlier version :http://www.invalidsoftware.net/Objectivity/files/Objectivity.zip

Besides neither language is perfect, which is why my current project with pskyboy, is designing and creating a new language. This will be our perfect language

EDIT:- There isn't that much framework to add, if your happy with the basic C++ features. With the __main and __atexit functions, and linking to your compilers c++ support library, you can have all the lovely features of C++ except RTTI and EH. (Which in turn means no Polymorphism and pure virtual functions, which rely on RTTI)

[chrisa128]

I started in Assembly, and to a command line stage but then I heard about DJGPP and moved to C.

Since then my development has got easier and faster along with being easier to understand and follow.

[Pype.Clicker]

i've been giving a quick look to whyme_t's previous C++ kernel, and it doesn't appear as a major improvement to write all the low-level stuff in C++ (i mean, is there really a need for CPU->reboot() when you know you will only have one instance of CPU ? Isn't cpuReboot() as much efficient ?)

IOPorts, timer, etc. don't gain from being in C++ ... imho, it only becomes interresting to shift towards OOP when you reach the drivers programming, etc. Mainly because at that level, you start to have inheritence, interface conformance, etc.
But if your design isn't as weird as mine, memory management, multithreading and basic (console) I/O can be performed in plain C without losing on the code style.


Maybe the best approach would be a mix of the two ... starting with C for the core of the kernel and using C++ for more awkward stuffs like modules management, device drivers, etc.

[DarylD]

My approach is a mix. My kernel is pure C, but my API library and headers will be c++ because there are a few nice advantages to having classes as the app coding level.

Although, I am finding it a little tricky in some respects its working fine for me now and is certainly much cleaner than my old C API.

Daryl.

PS. Personally I believe both languages are very "dirty" in comparison to more modern languages. Although java is *WAY* too wordy it does seem better designed. c# looks quite nice, but not ideal for OS development though.