flat assembler
Message board for the users of flat assembler.

Index > Heap > C vs C++ for kernel programming?

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
DataHunter2009



Joined: 10 Jun 2005
Posts: 144
DataHunter2009
This isn't related to FASM, so I figured I shouldn't post it in the OS Construction forum...

Anyway, I just bought "C++ for Dummies", and I really like it so far. So, I got to thinking about kernel programming with C++.

Has it been done before? Can an object oriented kernel be better than a kernel written in C? What are the ups and downs of writing a kernel in C++?

Any info you can give me would be appreciated! Very Happy
Post 27 Sep 2006, 18:50
View user's profile Send private message Reply with quote
HyperVista



Joined: 18 Apr 2005
Posts: 691
Location: Virginia, USA
HyperVista
Hello DH2K9 - sure you can program kernel code in C++, but it's not really recommended. There's an interesting debate in the Kmode community regarding your question. Microsoft published a paper titled, "C++ for Kernel Mode Drivers: Pros and Cons" back in 2004. I hope you find it helpful.

http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx
Post 27 Sep 2006, 19:32
View user's profile Send private message Visit poster's website Reply with quote
DataHunter2009



Joined: 10 Jun 2005
Posts: 144
DataHunter2009
Thanks for the link! I think I understood some of that... mostly that some C++ features may not work and some of the more advanced variable types (floats, etc) might not be functional on some processors. But, I'm not a kernel master, and I mostly do OS dev as a hobby. So, if I'm wrong about any of that, please tell me.
Post 27 Sep 2006, 20:07
View user's profile Send private message Reply with quote
arafel



Joined: 29 Aug 2006
Posts: 131
Location: Jerusalem, Israel
arafel
Language that tries to hide as much as possible stuff from the developer (like memory management in C++) is not a best choice for kernel development.
Post 27 Sep 2006, 20:07
View user's profile Send private message Reply with quote
DataHunter2009



Joined: 10 Jun 2005
Posts: 144
DataHunter2009
Quote:
Language that tries to hide as much as possible stuff from the developer (like memory management in C++) is not a best choice for kernel development.

I thought memory management in C++ was a Standard C++ Library thing. Wouldn't I still have to define my own memory management functions?
Post 27 Sep 2006, 20:16
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
DataHunter: then "new" and "delete" wouldn't work without linking STL?
Post 27 Sep 2006, 20:51
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
arafel



Joined: 29 Aug 2006
Posts: 131
Location: Jerusalem, Israel
arafel
DataHunter,
Yes, you will have to implement your own mm functions.
But mm is probably not the only negative aspect. Think of RTTI, Exceptions, C++ Standard lib port to your kernel (in case you decide to go that way), that you will have to heavily modify/re implement. Of course you may disable all that, but what would be the point to use C++ then?

Imo it would take much more effort to develop a decent kernel in C++ than in C (assuming a good OO knowledge).
Post 27 Sep 2006, 20:58
View user's profile Send private message Reply with quote
DataHunter2009



Joined: 10 Jun 2005
Posts: 144
DataHunter2009
I've been researching a bit more about this. I found an article on the MegaTokyo OSFAQ that talks about a C++ kernel. From what I've read, it seems like a huge hassle to even get it running. As arafel pointed out, I would have to disable most of the cool C++ functions to make it all work correctly. So, since I'm new to OS dev, maybe C++ isn't the way to go at the moment...
Post 27 Sep 2006, 21:50
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
generally, C++ is not language for complicated flow contructs, required by kernel. C is not too, it can be done only thanks to non-HLL non-structural asm hacks like setjmp()/longjmp().
Post 27 Sep 2006, 22:30
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Maverick



Joined: 07 Aug 2006
Posts: 251
Location: Citizen of the Universe
Maverick
arafel wrote:
DataHunter,
Yes, you will have to implement your own mm functions.
But mm is probably not the only negative aspect. Think of RTTI, Exceptions, C++ Standard lib port to your kernel (in case you decide to go that way), that you will have to heavily modify/re implement. Of course you may disable all that, but what would be the point to use C++ then?

The fact that you have a gun and no enemies doesn't mean you MUST suicide. Things like RTTI and EH were included in the C++ standard because many programmers in the committee wanted them to be included. Nobody forces you to use them (or even claim they should be used extensively), nor suggests that they're useful in all circumstances. Personally I never use them, having my own runtime type system and exception handling mechanism. I don't use ANY standard library function either, because I coded all my modules and use C++ as a "high level assembler", and I don't think I'm violating any C++ standard by writing my own libraries.

Anyway, I personally think++ that mentioning the existance of RTTI and EH in the ISO C++ as a motivation to affirm that C++ is not a good language for kernel development is a poor motivation.

If used judiciously, C++ can be much, much better than C in all regards. It is C incremented after all, and all that C does C++ does as well. Of the added features you can (and should) use only what fits the specific needs. Otherwise one could also affirm that C is not suitable because, just because C has function pointers, you MUST use function pointers for all function calls.

_________________
Greets,
Fabio
Post 28 Sep 2006, 10:55
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
C++ is fine for kernel development, but I personally wouldn't use RTTI and EH, nor the standard library (you'd have to re-implement a bunch of that anyway, for obvious reasons).

C++ has better typechecking == good, and constructors/destructors can be used to make code safer with regards to locks and resource leaks.
Post 28 Sep 2006, 13:29
View user's profile Send private message Visit poster's website Reply with quote
arafel



Joined: 29 Aug 2006
Posts: 131
Location: Jerusalem, Israel
arafel
Maverick wrote:
Anyway, I personally think++ that mentioning the existance of RTTI and EH in the ISO C++ as a motivation to affirm that C++ is not a good language for kernel development is a poor motivation.

That wasn't my point.
It's not the existence of some C++ features that makes it inappropriate for kernel development, but the fact that you will need to turn (or re implement) most of them (features that mostly make C++ what it is. of course C++ is much more than just throw or typeid, but I am currently referring only to such features) off to create a kernel. RTTI and EH is probably not the only thing that will need to be disabled.

Quote:
If used judiciously, C++ can be much, much better than C in all regards.


While in general I completely agree with you, but in my opinion in kernel development case it's not so true. It only becomes true if you are ready to spend additional n time on fixing C++ specific stuff.
Post 28 Sep 2006, 15:41
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
(from the UnixLite FAQ):

Quote:

Is c++ suitable for system programming?

We only use plain c++ functionality: member function, single inheritance, and virtual function. That's enough. We think there is no essential difference between c and c++ without using the following c++ features:

  • exception handling
  • multiple inheritence
  • run time type identification
  • operator overloading except new and delete
  • template magic

Post 28 Sep 2006, 18:46
View user's profile Send private message Visit poster's website Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost
Maverick wrote:

If used judiciously, C++ can be much, much better than C in all regards. It is C incremented after all, and all that C does C++ does as well. Of the added features you can (and should) use only what fits the specific needs. Otherwise one could also affirm that C is not suitable because, just because C has function pointers, you MUST use function pointers for all function calls.


C++ binaries are larger than C binaries and no faster Wink

C++ is also not a superset of C, it is a different language, research before making assumptions.

_________________
redghost.ca
Post 29 Sep 2006, 07:21
View user's profile Send private message AIM Address MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
RedGhost wrote:

C++ binaries are larger than C binaries and no faster Wink

Bullshit. Just because you name a file .cpp or .cc instead of .c won't make the output larger. It of course depends on which features you use. And actually, in many cases, C++ code will will be faster than C code - compare std::sort against qsort().

RedGhost wrote:

C++ is also not a superset of C, it is a different language, research before making assumptions.


It is mostly a superset of C, with a few errors corrected. Clean C code compiles fine with a C++ compiler, dirty C code needs fixes.

_________________
Image - carpe noctem
Post 29 Sep 2006, 07:43
View user's profile Send private message Visit poster's website Reply with quote
arafel



Joined: 29 Aug 2006
Posts: 131
Location: Jerusalem, Israel
arafel
f0dder wrote:

Bullshit. Just because you name a file .cpp or .cc instead of .c won't make the output larger.

yeah, how about structures? even empty structure in C++ is one byte long. Razz
Post 29 Sep 2006, 07:54
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
arafel wrote:
f0dder wrote:

Bullshit. Just because you name a file .cpp or .cc instead of .c won't make the output larger.

yeah, how about structures? even empty structure in C++ is one byte long. Razz


That's a pretty degenerate case, isn't it? Haven't bothered to look what The Standard says, but VC++ doesn't support empty structs in C mode, but sure does take 1 byte in C++ mode. GCC 3.2.2 with "-ansi -pedantic" warns about empty structure, so I guess it's nonstandard.

_________________
Image - carpe noctem
Post 29 Sep 2006, 08:19
View user's profile Send private message Visit poster's website Reply with quote
arafel



Joined: 29 Aug 2006
Posts: 131
Location: Jerusalem, Israel
arafel
f0d, it was a jest Smile

It's interesting though that gcc with -ansi -pedantci does that, I thought it would just ignore empty structs.
Post 29 Sep 2006, 08:47
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
arafel wrote:
f0d, it was a jest Smile

It's interesting though that gcc with -ansi -pedantci does that, I thought it would just ignore empty structs.


It only gives this as a warning, though... but VC++ refuses to compile it in C mode. In C mode, ignoring the warning, GCC does say 0 bytes for the empty struct, and 1 byte in C++ mode, so The Standard probably has something to say.

I don't find empty structs particularly interesting though, much less than the already boring "hello, world" examples Smile

_________________
Image - carpe noctem
Post 29 Sep 2006, 08:54
View user's profile Send private message Visit poster's website Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost
f0dder wrote:
RedGhost wrote:

C++ binaries are larger than C binaries and no faster Wink

Bullshit. Just because you name a file .cpp or .cc instead of .c won't make the output larger. It of course depends on which features you use. And actually, in many cases, C++ code will will be faster than C code - compare std::sort against qsort().

RedGhost wrote:

C++ is also not a superset of C, it is a different language, research before making assumptions.


It is mostly a superset of C, with a few errors corrected. Clean C code compiles fine with a C++ compiler, dirty C code needs fixes.


Oh does it? News to me..

Code:
long *a;
void *b;

a = b;
    


Compile that in C++, oh wait you can't, need a ridiculous cast.

Code:
struct template {
    char *this;
    void *class;
};
    


Now compile those... oh wait..

C allows struct, union, and enum types to be declared in function prototypes, whereas C++ does not. A struct, union, or enum declaration in C++ declares an implicit typedef, while in C it does not... C++ compilers prohibit goto from crossing an initialization, while C does not..

Shall I continue?

Also, the "run time" isn't the code generated by the language, and the speed is system and implimentation dependant... so pretty bad example.

Take GCC, it compiles C and C++, but the C++ generally has hidden calls and parameters, (constructs, this pointers etc) which leads to larger binaries, and yes it is "easier" to programme in C++, but I don't care about easy Wink

_________________
redghost.ca
Post 29 Sep 2006, 22:16
View user's profile Send private message AIM Address MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.