C++ vs C

[falconfx]

So nobody is able to say surely why C++ shouldn't be used in kernels.
I imagine this would mean there's no impediment with it.

By the way, I want to make a comparison between two GUI toolkits: QT and GTK+. The former uses C++ while the latter uses C.

IMHO, QT programming is much simpler and easier than GTK's. Is it just a case?

I will likely make a mistake writing my OS in C++, but trying doesn't hurt...

C++ is considered the natural evolution of C...
... then C++ kernels will be the natural evolution of (current) C kernels

[bluecode]

GUI toolkits writte in C++ are most likely more elegant/easier to use, because C++ is object-oriented and gui's are also oo.

I will likely make a mistake writing my OS in C++, but trying doesn't hurt...

If you stick to the features of C++ that come for free, then there is nothing to fear. Then C++ is just the OO/template C It's also always possible to use the C programming paradigms in C++.

[Candy]

C++ allows you to encapsulate anything you don't want to think about anymore in small classes that do the work for you. That's both a very very powerful concept as well as a way to make very inefficient code. You can make your own sorting algorithms so easily using a bit of STL stuff that you'd be quite tempted to do just that. Against that, your implementation probably is slow compared to qsort or heapsort or such. You can so easily make code that looks very clean but isn't working properly. Or worse, that is working properly, but fragile (you can't change it much without breaking it) and slow.

On the other hand, if used properly, it can make your code a whole lot cleaner and less obfuscated by encapsulating all operations with dependencies in nice wrappers. Common things are mutex lock wrappers that auto-unlock your mutex at the end of their scope and auto-free things that automatically free the object they contain at the end of their scope. Got the first in my OS design to clean up mutex code and for handling critical sections or best-not-to-interrupt sections in user code.

[Kemp]

My main reason for using it is for the few drivers I'm building into the kernel. For instance, I can do things like

Code: Select all

#include "ata.h"

DeviceInfo dev0;
ATAController ata_chan1(CHAN_PRI);

if (ata_chan1.DevicePresent(0) && ata_chan1.DeviceType(0) == TYPE_ATA) {
   ata_chan1.DriveRef(0)->GetDeviceInfo(&dev0);
}

Ignoring of course the fact that the ata stuff is in its own namespace to prevent name collisions (there would be a couple of 'using's at the top). I was going to use an enumeration for those parameters that are 0 (drive number) but it seemed overkill for two values, I'll probably add a couple of consts for it so you have nice names but don't have to do casting to get an actual value out of them. Slightly philosophical question, is DEV_0 and DEV_1 easier to understand than 0 and 1?

[DynatOS]

Linus is definitely not a guru, but I think he emphasizes a pretty good point. I think the entire focus should be on why we have so many different programming languages. IMHO, it is because those languages are designed to solve programming tasks in a specific manner. In short, you are supposed to use the right tool for the right job.

You can justify as to why you should/shouldn't use C++ for OS Kernel development until you are blue in the face. It doesn't change the facts at hand.

If you are out to prove that C++ can be used for OS Dev purposes, more power to you. However, I can tell you that you are not proving much because you will spend most of your time making exceptions to the language to fit your needs than you will using it.

Once you spend more time changing a tool (such as a programming language) to fit the job than you do completing it... it is a sign that you should change tools or design a new one.

If you spend all your time trying to turn C++ (or some other language) into the one "perfect tool", prepare to face the consequences of such single-mindedness. Don't let me stop you from running in circles, though.

Now to offer a more relasitic approach. C++ is a language designed to solve problems from the top-down. OS Kernel development is a systematic process of solving problems from the bottom-up. You should probably approach it, at least, by developing the bare parts of the kernel and an interface using a bottom-up language such as ASM or C. Once that portion is complete, you will have the foundation to interface your C++ programming efforts to your heart's content

[Kemp]

However, I can tell you that you are not proving much because you will spend most of your time making exceptions to the language to fit your needs than you will using it.

Once you spend more time changing a tool (such as a programming language) to fit the job than you do completing it... it is a sign that you should change tools or design a new one.

Actually no, I'll have the same stuff in asm as I would if I was using C, and the same stuff in C++ as I'd have in C. The only difference is I like C++ better. The odd thing I'll use C syntax for will be because I'm lazy rather than to try to get it to do something it's not meant to.

Why is there this huge mass of opinion that C++ hides all the stuff you want to be able to use? It doesn't, it just gives you access to them in a different way. If people don't like this different way then that's fine and they shouldn't use it, but it doesn't make it any less suited just because they think like that. And in reference to those that say the language requires too much extra code to support, I suggest you check out the OSFAQ and think about what's actually needed. All the nice fancy stuff (classes, templates, new/delete, etc) that you actually choose C++ for don't require any support at all, the exception being new and delete obviously which require roughly the same amount of support as malloc and free do.

Yes, I'm biased for C++, but I don't put down anyone else's language of choice as I don't know enough about them to make judgements. Try the same approach

[DynatOS]

Yes, I'm biased for C++

I can tell by your emotional and short-handed response

but I don't put down anyone else's language of choice as I don't know enough about them to make judgements. Try the same approach

This is where you and I differ, because I have studied and used various programming languages... including our discussion of ASM, C and C++

I never put down C++ as a language of choice, I only suggested a more realistic approach to using it... foregoing the faulty "perfect tool" mentality that most people possess.

To be dead honest, most arguments about why you should program in language "X" over language "Y" stems from the ignorance and laziness in not learning other programming languages. I tried not to contribute to that flamewar by commenting on the things I *do* actually know about

A Swiss-army knife is nice to have around and easy to carry... but it is no replacement for the tool shed that dedicated programmers should have

[Candy]

but I don't put down anyone else's language of choice as I don't know enough about them to make judgements. Try the same approach

This is where you and I differ, because I have studied and used various programming languages... including our discussion of ASM, C and C++

I never put down C++ as a language of choice, I only suggested a more realistic approach to using it... foregoing the faulty "perfect tool" mentality that most people possess.

I prefer C++ because it allows me full expressivity (near full, to be entirely correct) of all things I'd like to say in a programming language. Most other languages limit me, especially by only allowing single inheritance, from all sorts of nifty very useful things I'd like to do. Those nifty tricks aren't just bull or my happy-thing, I've used them to make maintainable production code in a few days instead of a few weeks.

To be dead honest, most arguments about why you should program in language "X" over language "Y" stems from the ignorance and laziness in not learning other programming languages. I tried not to contribute to that flamewar by commenting on the things I *do* actually know about

There are a whole lot of languages that allow a whole lot of things. There is no language that allows everything, if only because some things are each others complement.

A Swiss-army knife is nice to have around and easy to carry... but it is no replacement for the tool shed that dedicated programmers should have

C++ isn't just a swiss army knife. It does have a few drawbacks though, which you should most certainly know of. One of the most important drawbacks I know about C++ in its full glory is that it is so incredibly complex that I can make stuff that some people would never understand, even if they tried nothing other. I've tried a few things where I was halfway trying to bend my thoughts around the language more than the other way around. The point of this is, you should be able to write code that somebody else understands. The versatility of C++ is therein also its main drawback, if somebody else tries to read your code he's going to fail if you can't explain it properly or if it's not self-containing.

In other words, make your code self-contained as much as you can and if not possible, expose as little complex stuff as you can. I've got work code that contains a few classes I can barely read, but given those classes as a token, the rest becomes a lot easier. The classes do what they must and don't show their internals to anybody else. That lead me to leave them in there.

My OS framework also contains a bunch of complex thingies, which make the code nearly incomprehensible (and led to me mailing with the GCC crew about something I figured was a bug - I still disagree, but now with the language). It is however mostly contained and I'm still looking how to contain it further. It allows a bunch of powerful things you otherwise wouldn't be able to do, which I can explain in only a few pages.


In other words, choose the language that fits the requirements - and all of them. Human readability and co-worker compatibility come very high in that scale. If you're only working for yourself, like most people here are (some people?) you can do pretty much all you want. Unsurprisingly, some 90-95% of my own projects is in C++ (with the remainder for C#, since it's trivial for UI stuff in windows).

[Kemp]

I personally wasn't arguing for X over Y, the actual argument was about whether C++ was suitable for OS deving.

I never put down C++ as a language of choice, I only suggested a more realistic approach to using it... foregoing the faulty "perfect tool" mentality that most people possess.

Actually, your post was putting it down, which is why I responded like that. Your "realistic approach" was to use the same language as everyone else, which I have already had success without doing. As for the perfect tool part, I guess I have given the impression that I consider C++ to be my perfect tool, but I honestly don't. I see it has limitations and such, I just find its particular combination of advantages and limitations to be more aligned with my style than the alternatives.

Anywho, as I said quite a few posts ago, I'm not here to argue. I will attempt to rebuff any critisism that I feel to be unfounded though.

[mhaggag]

I think the entire focus should be on why we have so many different programming languages. IMHO, it is because those languages are designed to solve programming tasks in a specific manner. In short, you are supposed to use the right tool for the right job.

Both C and C++ are "system programming languages". Anything that C can do, C++ can--remember that there's a large overlap between the two.

However, I can tell you that you are not proving much because you will spend most of your time making exceptions to the language to fit your needs than you will using it.

Procedural programming is one of the main paradigms supported by C++. Which is what you'll be doing in C. Doing it in C++ is not an "exception to the language".

Now to offer a more relasitic approach. C++ is a language designed to solve problems from the top-down. OS Kernel development is a systematic process of solving problems from the bottom-up. You should probably approach it, at least, by developing the bare parts of the kernel and an interface using a bottom-up language such as ASM or C. Once that portion is complete, you will have the foundation to interface your C++ programming efforts to your heart's content

I disagree with the description of the kernel development problem. A kernel is actually about solving high-level problems--the "architecture" part (i.e. x86, SPARC, etc) is the low-level part that you have to make sure "fits" the bottom of your design.

That's the same in every other problem domain. Creating Windows applications? The bottom of your design has to fit the Win32 API. And so on.

I think there's a false perception of procedural programming as being "C", and object-oriented and/or generic as being "C++". You can develop procedurally in C++ the parts you know are better modeled that way.

I have developed a kernel in C++, using procedural, object-oriented and even generic code (templates). Made things much easier IMO, and I could always look at the generated assembly and know what's going on.