OSDev.org

There are many kernels written in C++, maybe not windows or linux but others have.

JamesM wrote:

Candy wrote:

JamesM wrote: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.

I for one do not believe in any "complexity of implementation" thing. If it's complex, learn how it works because there's most likely a damn good reason it exists.

I do believe in only using stuff where it applies. Exceptions are intended to handle errors you cannot handle at the location they occur, but you can handle at a higher place in the call stack. In my OS the call stack usually doesn't represent the actual call being made, so exceptions are pointless. Global callbacks for specific kinds of failure are more usable, such as the new_handler that C++ uses when you run out of memory. I believe this is also how I'll handle hotplugging and so forth - global callback & return when the actual operation fails. If I find out that it is better to do this with exceptions, I won't hesitate a second.

RTTI and MI are complex things that have good places for using them. You should only use them in complex situations involving inheritance, which you would usually not encounter in an OS. If you do encounter them, adding MI / RTTI support is easier than working around it.

@Candy: I agree with you that exceptions (as every C++feature) are a good thing if used correctly, but I still would say that they should not be used in a kernel. Imho you have to put enough thought into the normal execution flow. If you want a preemptible kernel you add another execution flow, since interrupts could occur whereever IF=1 within the kernel. Then you add SMP/NUMA support and you have to worry about the execution flow that *other* CPUs might do while this CPU is somewhere. And *then* you would add yet another control flow through exception.

disclamer: I have *not* much experience with C++ exceptions.

To solsve the problem of local variables in my c++ kernel,
I stick to an executable format that will be loaded in memory.
The constructors and destructors will be found in the sections loaded in memory and i do not have to bother anymore about it.
Instead of writting a kernel that will be a flat binary and bother myself about the overhead of calling using nasm.
They must and they will be called,sooner or later........
I will be writting a tutorial on it soon......

To solsve the problem of local variables in my c++ kernel,

What problem is this?

I don't _fear_ or _hate_ C++, not at all.

I do however, think that for the most part, it's overkill for Kernel development.

Personally, I don't use it simply for the fact that it requires a gigantic runtime, in order to use all of it's nifty features (exceptions, etc).

Sure - You can use _most_ of the language, without that much burden (new, delete, templates, etc...). But, In my eyes - the language is operating in an uncomplete state...

Why use C++ in a C-ish way, when I can just use C? (TEMPLATES!, which ... can for the most part, be emulated using crazy #defines ... )

Especially when it's not _that_ hard to use C in a completely objective way (yes, you heard me right).

~Z

zeii wrote:I don't _fear_ or _hate_ C++, not at all.

I do however, think that for the most part, it's overkill for Kernel development.

Personally, I don't use it simply for the fact that it requires a gigantic runtime, in order to use all of it's nifty features (exceptions, etc).

Sure - You can use _most_ of the language, without that much burden (new, delete, templates, etc...). But, In my eyes - the language is operating in an uncomplete state...

Why use C++ in a C-ish way, when I can just use C? (TEMPLATES!, which ... can for the most part, be emulated using crazy #defines ... )

Especially when it's not _that_ hard to use C in a completely objective way (yes, you heard me right).

~Z

Um you might also want to program with Objects. Even if they are a little obtuse in C++. There's plenty of advantages to C++ and when you can call normal C functions I really don't see anything wrong with C++ as a language to write a kernel in.

Quote:
To solsve the problem of local variables in my c++ kernel,


What problem is this?

I am sorry ,i was talking about global variables,not local variable.

AdHawk, read my above post...

I can code with 'objects' in an 'objective' way in pure ANSI C.

Search Objective ANSI C in Google or something. Youll see.

~Z

Maybe its becuase i am in love with the C++ language itself that i find it so exciting writing a kernel with it.
I heard objective C has also a lot of issues with runtime support.
Is that right?

zeii wrote:I can code with 'objects' in an 'objective' way in pure ANSI C.

You can. But ANSI C is not object oriented, meaning that it doesn't support the notion with syntactic suggar.

I like my public / private, my constructors / destructors and the like. ANSI C doesn't give you that.

einsteinjunior wrote:Maybe its becuase i am in love with the C++ language itself that i find it so exciting writing a kernel with it.
I heard objective C has also a lot of issues with runtime support.
Is that right?

There is a lot you can do with C++ even without run-time support, but Objective-C without run-time support is basically just C.

So how do you add runtime support to your Objective C kernel?

einsteinjunior wrote:So how do you add runtime support to your Objective C kernel?

You'd best ask someone with an Objective-C kernel. But I'd at least start by understanding this API.