The fear of C++ in operating systems kernels

[einsteinjunior]

I just wish to know why people fear ( or should i say dislike) so much to write an OS in C++.
Whats wrong with C++?
In any case,i am designing a new Operating System Architecture for Object Oriented Language so people will think much more about writting object oriented kernels.
You will surely be surprised by the end result......

[Colonel Kernel]

I chose not to use C++ in my kernel, not because I feared it, but because I wasn't interested in learning how to implement the ABI. I wanted to keep things as simple as possible so I could focus on learning the kernel implementation details rather than language implementation details.

If you're wondering about the Linux kernel developers' negative opinions about C++, I think it's a lot of FUD and techno-religious zeal more than anything else.

[Laksen]

... a lot of FUD and techno-religious zeal more than anything else.

QFE

[Combuster]

There's nothing inherently wrong with C++. The main reason people use C is that C++ is slightly crippled in a freestanding environment. You can't use part of the language features, nor the STL libraries without implementing a runtime first. Some of those features practically require a working kernel while you yet have to build one.

The advantage of C is that you can use everything that is part of the actual language without having to care about that nonexistant runtime. It's basically a burden less, which people don't mind sacrificing over the absence of OOP features.

People make fun of me for writing an OS with Basic, because there the runtime problem is several magnitudes larger than in C++.

[AJ]

Hi,

I'm writing my kernel in C++ and have previously written test-kernels in C. I have working new and delete operators, pure virtual functions, global and static objects and palcement new. I do not have RTTI or exceptions, but do not want these in the kernel (I plan to port libsupc++ once I have worked on my system call interface).

Personally, I much prefer using C++ to C and this is something which is going to vary a lot depending on the programmer. Pick whatever you are more comfortable with. Please read the wiki C++ page for more detail, but to give you some thoughts:

1) New and Delete
No worse than in C. You need some kind of working malloc() anyway. Once you have malloc() and free(), new and delete just sort of happen. A word of caution: make sure your heap manager works reliably. Once you have new and delete, a lot of your memory allocations seem to happen 'transparently' - or you think about it less. If you heap manager is buggy, you will have a hell of a job debugging anything else.

2) Global and Static objects
Really easy. My architecture-dependent code fires up, starting the physical memory manager, paging and the heap manager. Once this has happened and New and Delete work, a support function cycles through calling all global and static constructors (found from a linker script label). In this way, a global object can use New/Delete in its constructor.

To be honest, these are the two main things to implement for C++ support. Placement New and Pure Virtual Function support, just need a few lines of code. Decent exception handling and RTTI are a different kettle of fish - better to port an existing standard library a bit later on, IMHO.

As for bootstrap code, my entry point is a C++ main function. This is called directly by my boot loader which also passes an argc and argv, containing parameters passed from the boot loader with some machine state information.

Anyway, if you want to code a C++ kernel and are already very familiar with C++, go for it!

Cheers,
Adam

[JamesM]

I concur - there's nothing scary about writing a kernel in C++. Pedigree's entire C++ support file comes to 2.5KB, and most of that is the BSD licence at the top! The most complex bit of C++ support code is probably trawling through the initial constructor list, but when you've got it simplified this is only a few lines:

Code: Select all

/// Calls the constructors for all global objects.
/// Call this before using any global objects.
void initialiseConstructors()
{
  // Constructor list is defined in the linker script.
  // The .ctors section is just an array of function pointers.
  // iterate through, calling each in turn.
  uintptr_t *iterator = reinterpret_cast<uintptr_t*>(&start_ctors);
  while (iterator < reinterpret_cast<uintptr_t*>(&end_ctors))
  {
    void (*fp)(void) = reinterpret_cast<void (*)(void)>(*iterator);
    fp();
    iterator++;
  }
}

And even that could be reduced more, but I decided not to, for clarity.

There's nothing to fear about C++, and the purported speed reduction is actually rubbish: It is only seen when using virtual functions, which have no native equivalent in C anyway! You get things like object orientation and inheritance for free.

I would advise avoiding multiple inheritance, RTTI and exceptions though.

[skyking]

The bad part with C++ is not what people seem to think. With exceptions disabled you don't get any overhead using C++ (of course you could use virtual functions, but the equivalent code in C will boil down to the similar solution).

The real issue is that C++ is not a simplier language but rather much more complex. There's a lot of mechanisms in the language that generate function calls and other code implicitely if you don't pay attention. There may also be situations where the language is not doing quite what you might expect (dependent on what your knowledge of the language is). You have to know what's going on behind the scene, more so than in C (then the recommendations become obsolete because you'd know what you pay for RTTI, exceptions and virtual functions and so on).

C++ is mostly OK, but make sure you know the language well.

[Candy]

I would advise avoiding multiple inheritance, RTTI and exceptions though.

Why?

[binutils]

i have never heard of anything about os written in c++ in first place, even microsoft windows

[Candy]

i have never heard of anything about os written in c++ in first place, even microsoft windows

Maybe you should start listening then?

[JamesM]

I would advise avoiding multiple inheritance, RTTI and exceptions though.

Why?

The main reason being that the implementation of those three things are extremely complex, and could take a non-veteran c++ user unawares, along with the fact that they require more runtime assistance (especially rtti).

Apple decided against them because they were "unsafe", in their words, for their project. I forget which one it was - could have been IOKit, or some part of macosx. I forget because I've lost the url I read it on.

[einsteinjunior]

I would advise avoiding multiple inheritance, RTTI and exceptions though.

I will really not implement RTTI and multiple inheritance in my OS,
they are way tooo complex to be implemented at the moment.
So for all of you wanting to writre a C++ opearing system,you should stick to very simple designs,only put in place "useful abstractions" keep away from exception handling.
Although a structured exception handler could help.But the design is also complex to put in place.

[froggey]

My OS is written in C++ and I've been using multiple inheritance without needing any extra runtime support code. However it could be that I've just not used it in such a way that requires runtime support.

[JamesM]

AFAIK MI doesn't require runtime support - it can however confuse some people newer to C++ as the address of subclassed objects depends on which class it is cast to (this was explained poorly, but people familiar with how MI is implemented should know what I'm trying to get across!!)

[binutils]

i have never heard of anything about os written in c++ in first place, even microsoft windows

Maybe you should start listening then?

come on, no c and asm in microsoft windows?

afaik, core is c&asm, wrap in c++. wrap in c++ library.

--
PS: if you don't believe me, see winnt leak source or reactos-0.34(current version) source