OSDev.org

Hi!

I have been thinking about writing my os using C++ instead of C.
I consider C++ classes much more versatile than C structures and I think it would be great to treat hardware resources as classes.

I read the osfaq's page about C++ and I think I can write my os without error handling, rtti, etc...

But I also read about many articles that suggest not to use C++ in kernels. Even linux developers stay away from it. Why?

I want this to be a topic where to discuss about pros and cons of using C++ in an operative system.

Bye.

falconfx wrote:But I also read about many articles that suggest not to use C++ in kernels. Even linux developers stay away from it. Why?

Bigotry.

I don't see any technical reason not to use C++. I think whether you should use it really depends on how well you know the language and on what you want to learn or accomplish by using it.

I don't use C++ in my kernel, but only because I'm more interested in learning about OS implementation than in learning how to implement parts of a C++ run-time environment in my kernel. That's something I might tackle in my next kernel (which at this rate may be in my next lifetime ).

falconfx wrote: Hi!

I have been thinking about writing my os using C++ instead of C.
I consider C++ classes much more versatile than C structures and I think it would be great to treat hardware resources as classes.

I read the osfaq's page about C++ and I think I can write my os without error handling, rtti, etc...

But I also read about many articles that suggest not to use C++ in kernels. Even linux developers stay away from it. Why?

I want this to be a topic where to discuss about pro and cons of using C++ in an operative system.

Bye.

An object-oriented design for a kernel could be quite nice. I don't know how efficient it would be, but if you were careful I'm sure you could have a perfectly acceptable hobbyist OS with a good clean codebase. It's tempting to once again restart my project in C++ - the only real dissuading factor is that I don't know C++ half as well as I know C. Another (slightly weak, but hey) reason that you might want to use C++ is that it mangles the function names so that you can retreive (at runtime) the name of the function and the types of the arguments to that function (if I understood the FAQ correctly - I'm open to correction) - which lets you have a little more information for debugging (which in turn might let you have a more powerful debugging console - if you're going that route).

I think one of the main reasons people stay clear of C++ (just stabbing in the dark here) is because, to get a 'full' version of the language and standard, you have to put in more work than with C (where you really need 'just' the stdlib - and pdclib's heading gradually towards removing most of that grunt-work). Also, I think Linux kernel developers will stay clear of C++ for 'historical reasons' - amongst them being the fact that the majority of the codebase is already in C (I came across a code analysis of it at one point, it's mostly C with a few bits of other languages (including, IIRC, Python, bizarrely - presumably a script run during compilation)).

Also, I don't know at all how the classes etc get compiled - so that could conceivably go either way in terms of ease of stepping through the compiled code.

That's all that occurs to me though, I have no real experience to offer, sorry.

I'm using C++ for mine. It looks like it'll be a bit of a challenge getting full support in there, but once you have a few things working it should all fall into place. I think the reason Linux (kernel) developers stay away from it is because Linux was started in C and to change now would be pretty much a case of a complete rewrite.

I'm also using C++ for my whole os (kernel, server, apps). I don't yet have exception handling, but some parts of rtti (typeid works, but dynamic_cast is not implemented yet).
From the speed perspective I would say, that it's not slower than C or assembler. What really matters are the algorithms not the language.

@Midas: Yes you can retrieve the function declaration from the mangled name. You can also use the binutils tool c++filt for that job...

This article section should yield valuable answers.
http://www.tux.org/lkml/#s15-3

And, now something that made me laugh and will hopefully start a war, muhahaha.

# However, it is a more complex language and is less mature than C. The greatest danger with C++ is in fact its power. It seduces the programmer, making it much easier to write bloatware. The kernel is a critical piece of code, and must be lean and fast. We cannot afford bloat. I think it is fair to say that it takes more skill to write efficient C++ code than C code. Not every contributer to the linux kernel is an uber-guru, and thus will not know the various tricks and traps for producing efficient C++ code.
# (REG) Finally, while Linus maintains the development kernel, he is the one who makes the final call. In case there are any doubts on what his opinion is, here is what he said in 2004:

In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:

* the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
* any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
* you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is either

* (a) looking for problems
* (b) a C++ bigot that can't see what he is writing is really just C anyway
* (c) was given an assignment in CS class to do so.

Feel free to make up (d).

I feel you should continue writting a kernel in C++, and if you are planning should continue planning since it should not hurt to try. I would not mind trying it, but I prefer C only because I am just trying to go with a plain vanilla kernel.

Heh, I see Linus as being far far away from anything like a guru. So he wrote a basic kernel and then lived off the fact that he managed to get a load of people to try to fix all his mistakes (some of which are still causing a lot of problems)... big deal. Outdated arguments from a wannabe celebrity as far as I'm concerned.

@Kemp:
A interesting way to think about his comments. I wonder if he really did not do much work at all and it is only a indirect exaggeration of his assumed knowledge in the kernel field of computer science from this and many other articles that drives people to listen to what he writes instead of his actual knowledge. You could be right.

Even if that was sarcasm it was quite close to what I think Think about it, the vast majority of the existing Linux kernel wasn't written by him, he just started the ball rolling. Just because it got popular suddenly people see him as this big innovator who speaks only the Truth about all things programming related. AFAIK, the only thing he's really done for a long time is policy decisions, saying what is and isn't allowed as features in the "official" kernel source. As for his comments on C++, they're based on experience with trying it out (probably not even seriously) 14 years ago. Can you remember what systems we were using 14 years ago?

any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel

That quote especially is just wrong. There isn't any hiding of memory allocations, just a slightly different (and imho opinion cleaner) syntax that has the advantage of automatically called constructors for you if applicable.

I have no idea if he is right or wrong, but I mostly had fun posting it because it was controversal and I am not going to get pulled into a trap by trying to argue what I am unqualified to argue aka "The Language War By The Unqualified".


o ------>(Oh... look at that hole covered up with leaves.)
|/
|
/\ __ ^^..^^.^^^>___
\ /
\______/

That quote especially is just wrong. There isn't any hiding of memory allocations, just a slightly different (and imho opinion cleaner) syntax that has the advantage of automatically called constructors for you if applicable.

Do you mean cleaner because of fewer characters -- giving readability or something else?

Do you mean cleaner because of fewer characters -- giving readability or something else?

Not only cleaner in sense of readability, but it is also much easier to write exception safe code. That means in that case, that it is easier to write code without memory leaks, when exceptions occur.

Heh, don't worry about getting dragged in. I'll give my side of the argument everything I have but I don't hold grudges, I can just stop and say "fair enough, you feel different" anytime you want

I was thinking of allocating memory for objects (structs or classes depending on your favoured term, they're the same thing really). Say you want to create a pointer to a foo and initialise its variables to something useful. In C you would do:
in C++ you would do:
The constructor would be set up to initialise the variables for you. I like the fact that you can't mess up the amount of memory allocated and you can't accidentally not call the init function. Plus the line of code just looks neater to me, though that might just be me. Note that (amost) exactly the same code is called in both cases. Some memory is allocated for the object and then the init function is called (in C++ the class/struct's constructor would just be a function like the one in the C code that still gets passed a pointer to the memory just allocated, each class doesn't have its own set of functions).

Summary:
The same steps are performed in both cases using almost the same code behind it all, but in C++ the compiler generates more of it for you (and makes it look nicer) to allow you to get on with writing the program rather than worrying about the mundane details.

I like that, looks good.

Kemp wrote: Summary:
The same steps are performed in both cases using almost the same code behind it all, but in C++ the compiler generates more of it for you (and makes it look nicer) to allow you to get on with writing the program rather than worrying about the mundane details.

In my perspective, this is why theres so many recent people asking for help on some bug and turns out some pointer is not initialized or something. In my opinion you'd want to know what exactly is going on, exactly is your compiler generating. But I'm not purposing you shouldn't use C++.

I agree. Obviously at the lower levels your C++ might start taking on more C syntax for certain things that aren't nice to do, but in general the things C++ tries to hide are the things that can be safely hidden. Anywho, I'm not arguing, just stating my views