WHY NOT USE C++

[dc0d32]

Can somebone please TELL MY WHY I SHOULD ***NOT*** USE C++ FOR KERNEL DEVELOPMENT. what are the pros and cons of it?

I have a C kernel up and running, it is for i586+, has features such as user mode tasks with preemptive multitasking, rudimentary device driver support, paging etc. and some basic obvious things.

I know C++ language well. I won't be using exceptions. i also have coded basic functions to support some other C++ features such as global object construction etc., and the code for operators new/delete won't be much bigger [i have kmalloc()]. the test kernel with iostream and cout-cin works well.

Thanx.

[carbonBased]

A C++ kernel requires a lot more overhead, that's about the only reason I can see to not use it.

I've written kernels in C and C++, and the OO design of C++ is definitly nice. Once you've got the basic new/delete functionality and the proper linker scripts to support global constructors, etc, then you're already well on your way to having the runtime support, so I'd say go for C++.

One other disadvantage I can think of is name mangling -- this can make debugging a pain if you don't have the proper tools, and it can also make the C level interface to your apps a little convoluted (assuming you have a C level interface to your apps -- maybe the app interface itself is also C++).

Otherwise, the pros you already know -- an object oriented API which, if done correctly, reuses a lot of code and is very intuitive.

Cheers,
Jeff

[dc0d32]

thanks.
can you please mension the overheads, so that i may try to minimize[or eliminate?] them? another thing, i have seen people doing something like "some portions in C and some in C++", is this approach better? i am directionless.

[Legend]

Most would point out virtual function tables as a major overhead, as if a structure of function pointers (which would be the closest equivalent) would be free ...

[mikeleany]

One more disadvantage of C++ is that your code may not be as portable from one compiler to another, because of your methods of handling name mangling and global construction/destruction. But you probably already realize that.

[JoeyG]

Exactly. You must use a single C++ compiler when interfacing ASM\C, because every compiler mangles names differently. You will also need to know the name-mangling conventions of the compiler, and even then your code will not be as readable.

Objects are also difficult to handle in ASM, because they are like oddly-shaped arrays. I would stay with C when building a kernel, and then make your own C++ compiler for your OS when attempting this.

[carbonBased]

I'd just like to point out that if *IS* possible to write portable C++ code that can be interfaced with assembly langauge from any compiler by using the #extern "C" { } processor.

In this way, you can ensure that name mangling does not take place on a select few function calls which can be used to transfer control to and from ASM/C++.

This is common practice in C++ kernels and will allow your kernel to be compiled by several different compilers.

--Jeff