WHY NOT USE C++

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
dc0d32
Member
Member
Posts: 69
Joined: Thu Jun 09, 2005 11:00 pm
Location: Right here

WHY NOT USE C++

Post by 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.
User avatar
carbonBased
Member
Member
Posts: 382
Joined: Sat Nov 20, 2004 12:00 am
Location: Wellesley, Ontario, Canada
Contact:

Re: WHY NOT USE C++

Post by 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
User avatar
dc0d32
Member
Member
Posts: 69
Joined: Thu Jun 09, 2005 11:00 pm
Location: Right here

Re: WHY NOT USE C++

Post by 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
Member
Member
Posts: 195
Joined: Tue Nov 02, 2004 12:00 am
Contact:

Re: WHY NOT USE C++

Post by 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 ...
*post*
mikeleany
Posts: 3
Joined: Fri Nov 19, 2004 12:00 am
Contact:

Re: WHY NOT USE C++

Post by 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
Posts: 2
Joined: Sun Jun 26, 2005 11:00 pm
Location: Canada

Re: WHY NOT USE C++

Post by 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.
User avatar
carbonBased
Member
Member
Posts: 382
Joined: Sat Nov 20, 2004 12:00 am
Location: Wellesley, Ontario, Canada
Contact:

Re: WHY NOT USE C++

Post by 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
Post Reply