Which is good for os coding?

[Tolga]

Hi.

Im using C++(mingw) for os coding. But i wondered which is good for os coding? C or C++.

Advantages and disadvantages??

I prefer C++. Because it has class technology.

[Cheery]

I'm not sure about which is 'good', thought I know that c++ is definitely not 'optimal' language for such development. Thing is: it is complex, do not even think about self-hosting soon and early. From same reason writing a VM is horrible thing for it (sure you want to sandbox and debug your programs in your very own OS?). Because of it's syntax, you can't deploy it in your shell or use it in your configuration scripts, as structured data representation nor make syntax extensions. Not to say it is statically typed and requires manual generalisation. These defects eventually overrides the help of classes and RAII.

I do not say what would be the 'best' or most 'optimal' because I've not yet made up with myself.

What I know, this thread is a great heatpoint for some language flame wars to appear.

[Hadrien]

I hope people here are educated enough to avoid flame wars

Hi.

Im using C++(mingw) for os coding. But i wondered which is good for os coding? C or C++.

Advantages and disadvantages??

I prefer C++. Because it has class technology.

Well, as C++ is almost C with more features, if you don't need C++ specific features, you can stick to C. A matter of taste.

I found I was more productive by using C++ so this is the language I use for my OS. It's up to you. The most important thing is to know your language well.

[Dex]

As long as both languages can be used, it's best to chose the one you know best.

[Colonel Kernel]

I normally use C++ for userland development, but I chose C for my OS because it doesn't have a complex ABI that I would need to understand just to get things up and running. I'm still implementing my kernel in an OO style though -- C doesn't preclude this, it just means you have to be a bit more creative.

[TheQuux]

I'm still implementing my kernel in an OO style though -- C doesn't preclude this, it just means you have to be a bit more creative.

I'm doing the same thing, using structs with function pointer elements. For example,

Code: Select all

struct console {
    void (*putchar) (struct console *THIS, char asc);
    void (*cls) (struct console *THIS);
        .
        .
        .
    struct color fg;
    struct color bg;
};

Then there's struct k_queue, which acts like a template... that one has been in the last few releases of my kernel.

Is rgar how you're doing it, or are you using gobject-style OO (which features single inheritance, but not virtual functions)?

[Colonel Kernel]

rgar?

I'm doing things a little differently -- I'm basically modeling interfaces in C using structs of function pointers and other structs that are "fat references".

Code: Select all

typedef void (*IFoo_barFunc)( void* this );

typedef struct
{
    IFoo_barFunc bar;
} IFoo_itable;

typedef struct
{
    void* pObj;
    IFoo_itable* iptr;
} IFoo;

...
IFoo foo = GetAFooFromSomeWhere();
foo.iptr->bar( foo.obj );

I haven't bothered to model inheritance so far because my kernel hasn't needed it yet.

[Tolga]

But OS projects have more codes. So, for clearly code, C++ is very suitable.

[xyjamepa]

I think C is more suitable for os developing but
C++ is more modern programming language and i think
it has more tutorials online about many topics related
to os programming such as multitasking,memory management
and other stuff...
Thanx.

[Solar]

This isn't a clear-cut, black-or-white question. It is possible to use some of the C++ features (like namespaces, templates, classes, function overloading, stricter type checking etc.), without requiring any additional run-time support. I think that is a good choice for OS coding, as it gives you much of the syntactic suggar of C++ but doesn't cost you anything. (I certainly liked the kout object I coded for my OS project back then much better than any kprintf() I could ever have come up with, for the sheer "beauty" of it.)

Doing the full C++ thingy requires significant "magic" done with regards to operator new, exception support and some other minor parts. Especially exceptions don't come for free (although some techniques exist that make them nearly free).

[Colonel Kernel]

I suppose if I were really serious about OS dev (like for commercial gain) and not just doing it as a learning exercise, I probably would have chosen C++ instead.

From a learning point of view though, if I want to learn how to host a complex language run-time environment in my kernel, I'll choose a more interesting language than C++, like maybe Scala.

[Walling]

Doing the full C++ thingy requires significant "magic" done with regards to operator new, exception support and some other minor parts. Especially exceptions don't come for free (although some techniques exist that make them nearly free).

From what I "researched" on GCC and the C++ ABI used by it, you have to create a virtual machine executing DWARF instructions and also read complex structures of your kernel object file. Being very complex to implement for one thing (not well documented either), but also slow when throwing exceptions. So I dropped it. What is this nearly free solution you refer to? I'm interested! Maybe it could be implemented efficiently as well.

I already implemented typeid and dynamic_cast. Not that I use it. But for the fun of it. And I read it is used by the exceptions implementation. I like the syntactic sugar C++ offers. Actually I very much dislike C++ from an "full support implementation" point of view.

[Walling]

IFrom a learning point of view though, if I want to learn how to host a complex language run-time environment in my kernel, I'll choose a more interesting language than C++, like maybe Scala.

Yes, Scala looks interesting! I have thought about a virtual machine kernel a lot. I decided to implement multimethods (dynamic multi-dispatch) in the language I'm currently working on. I look forward to actually implement some of it, hopefully soon. I could start by writing a simple interpreter, when I decide on an object format. It is easier than a C++ runtime implementation

[Candy]

Doing the full C++ thingy requires significant "magic" done with regards to operator new, exception support and some other minor parts. Especially exceptions don't come for free (although some techniques exist that make them nearly free).

From what I "researched" on GCC and the C++ ABI used by it, you have to create a virtual machine executing DWARF instructions and also read complex structures of your kernel object file. Being very complex to implement for one thing (not well documented either), but also slow when throwing exceptions. So I dropped it. What is this nearly free solution you refer to? I'm interested! Maybe it could be implemented efficiently as well.

I already implemented typeid and dynamic_cast. Not that I use it. But for the fun of it. And I read it is used by the exceptions implementation. I like the syntactic sugar C++ offers. Actually I very much dislike C++ from an "full support implementation" point of view.

You must've misread that somehow. Where did you get the idea that DWARF was required by c++? DWARF is the debugging format that belongs with ELF. That would imply that all other platforms couldn't run c++ code - which most certainly is bullshit.

[Walling]

From what I "researched" on GCC and the C++ ABI used by it, you have to create a virtual machine executing DWARF instructions and also read complex structures of your kernel object file. Being very complex to implement for one thing (not well documented either), but also slow when throwing exceptions. So I dropped it. What is this nearly free solution you refer to? I'm interested! Maybe it could be implemented efficiently as well.

You must've misread that somehow. Where did you get the idea that DWARF was required by c++? DWARF is the debugging format that belongs with ELF. That would imply that all other platforms couldn't run c++ code - which most certainly is bullshit.

I got the impression from this document: http://www.freestandards.org/spec/books ... echpt.html

Then I read some of the DWARF 3 draft. It seems that it is platform independant because the instructions are not specific to any platform, ie. they can be interpreted by all.

But maybe I've misread it. Maybe the .eh_frame is only for debugging.